Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

question(groups): help with configuring versionGroups #209

Open
rhefner opened this issue Apr 23, 2024 · 5 comments
Open

question(groups): help with configuring versionGroups #209

rhefner opened this issue Apr 23, 2024 · 5 comments

Comments

@rhefner
Copy link

rhefner commented Apr 23, 2024

Description

I have a package @myorg/remix where we keep common Remix utilities. It has peerDependencies set as follows:

"peerDependencies": {
    ...
    "@remix-run/node": "^2.8.1",
    "@remix-run/react": "^2.8.1",
  },

I upgraded our repro to @remix-run/**@2.9.0 today, but the peerDependencies above were not updated and I left them that way. I expected syncpack to clue me in on it, but it didn't... So after some digging, I found that if I don't have this entry in my versionGroups:

{
      label: 'All Remix dependencies use versions the @myorg/remix package is using',
      dependencies: ['@remix-run/!(eslint-config)'],
      dependencyTypes: ['**'],
      snapTo: ['@myorg/remix'],
    },

Then the 'Default Version Group' fails as expected. The moment I added it back, that group passes.

I've been looking through the code to try to figure out what's happening, but the Effect stuff is a little mind-melting and it's going to take me some time to make heads or tails of this. :)

Suggested Solution

None yet.

Help Needed

I would like to make a rule that makes sure @myorg/remix is the source of truth for all other packages when it comes to versions of @remix-run/** packages, with the exception of @remix-run/eslint-config. I thought snapTo was the right thing to use here, but it seems it's acting a bit wonky for me. Maybe I'm using it wrong?

@rhefner
Copy link
Author

rhefner commented Apr 23, 2024

Then the 'Default Version Group' fails as expected. The moment I added it back, that group passes.

I meant the reverse of this. If the All Remix dependencies use versions the @myorg/remix package is using is not in versionGroups, then Default Version Group succeeds. If it's present, then Default Version Group fails.

@rhefner
Copy link
Author

rhefner commented Apr 23, 2024

Here's an example of the output when the bad versionGroup entry is omitted:

➜ yarn syncpack list-mismatches
= Use workspace protocol when developing local packages ========================
    75 ✓ already valid
= Default Version Group ========================================================
✘ @remix-run/express 2.8.1 → 2.9.0 package1/package.json > dependencies [HighestSemverMismatch]
✘ @remix-run/node ^2.8.1 → ^2.9.0 remix/package.json > peerDependencies [HighestSemverMismatch]
✘ @remix-run/react ^2.8.1 → ^2.9.0 remix/package.json > peerDependencies [HighestSemverMismatch]
  1313 ✓ already valid
     3 ✓ can be auto-fixed

And when it's present:

➜ yarn syncpack list-mismatches
= Use workspace protocol when developing local packages ========================
    75 ✓ already valid
= All Remix dependencies use versions the @myorg/remix package is using =========
✘ @remix-run/express 2.8.1 → 2.9.0 package1/package.json > dependencies [SnappedToMismatch]
✘ @remix-run/node 2.9.0 → 2.8.1 package3/package.json > dependencies [SnappedToMismatch]
✘ @remix-run/node 2.9.0 → 2.8.1 package4/package.json > dependencies [SnappedToMismatch]
✘ @remix-run/node 2.9.0 → 2.8.1 package5/package.json > dependencies [SnappedToMismatch]
✘ @remix-run/node 2.9.0 → 2.8.1 package6/package.json > dependencies [SnappedToMismatch]
✘ @remix-run/node 2.9.0 → 2.8.1 package1/package.json > dependencies [SnappedToMismatch]
✘ @remix-run/node 2.9.0 → 2.8.1 package2/package.json > dependencies [SnappedToMismatch]
✘ @remix-run/node 2.9.0 → 2.8.1 package7/package.json > dependencies [SnappedToMismatch]
✘ @remix-run/node 2.9.0 → 2.8.1 package8/package.json > dependencies [SnappedToMismatch]
✘ @remix-run/node 2.9.0 → 2.8.1 package9/package.json > dependencies [SnappedToMismatch]
✘ @remix-run/node 2.9.0 → 2.8.1 package10/package.json > dependencies [SnappedToMismatch]
✘ @remix-run/node 2.9.0 → 2.8.1 remix/package.json > dependencies [SnappedToMismatch]
✘ @remix-run/node 2.9.0 → 2.8.1 package11/package.json > dependencies [SnappedToMismatch]
✘ @remix-run/react 2.9.0 → 2.8.1 package3/package.json > dependencies [SnappedToMismatch]
✘ @remix-run/react 2.9.0 → 2.8.1 package4/package.json > dependencies [SnappedToMismatch]
✘ @remix-run/react 2.9.0 → 2.8.1 package5/package.json > dependencies [SnappedToMismatch]
✘ @remix-run/react 2.9.0 → 2.8.1 package6/package.json > dependencies [SnappedToMismatch]
✘ @remix-run/react 2.9.0 → 2.8.1 package1/package.json > dependencies [SnappedToMismatch]
✘ @remix-run/react 2.9.0 → 2.8.1 package2/package.json > dependencies [SnappedToMismatch]
✘ @remix-run/react 2.9.0 → 2.8.1 package7/package.json > dependencies [SnappedToMismatch]
✘ @remix-run/react 2.9.0 → 2.8.1 package8/package.json > dependencies [SnappedToMismatch]
✘ @remix-run/react 2.9.0 → 2.8.1 package9/package.json > dependencies [SnappedToMismatch]
✘ @remix-run/react 2.9.0 → 2.8.1 package10/package.json > dependencies [SnappedToMismatch]
✘ @remix-run/react 2.9.0 → 2.8.1 remix/package.json > dependencies [SnappedToMismatch]
✘ @remix-run/react 2.9.0 → 2.8.1 package11/package.json > dependencies [SnappedToMismatch]
    44 ✓ already valid
    25 ✓ can be auto-fixed
= Default Version Group ========================================================
  1247 ✓ already valid

I thought it was strange that the Default Version Group mentions:

  1313 ✓ already valid
     3 ✓ can be auto-fixed

When it's working properly and:

  1247 ✓ already valid

When it's not.

@JamieMason
Copy link
Owner

Can you share your full config file or ideally share a reproduction that includes the package.json files?

@rhefner
Copy link
Author

rhefner commented Apr 24, 2024

Sure thing! Here's the config file for now - I'll try to get a sandbox up and running to reproduce:

// @ts-check

/** @type {import("syncpack").RcFile} */
const config = {
  semverGroups: [
    {
      range: '',
      dependencyTypes: ['dev', 'prod', 'overrides', 'resolutions'],
    },
    {
      range: '^',
      dependencyTypes: ['peer'],
    },
  ],
  source: [
    'package.json',
    'apps/*/package.json',
    'config/*/package.json',
    'lib/*/package.json',
    'templates/*/package.json',
  ],
  sortAz: ['contributors', 'dependencies', 'devDependencies', 'keywords', 'peerDependencies', 'resolutions', 'scripts'],
  sortFirst: ['name', 'description', 'version', 'author', 'type', 'sideEffects'],
  versionGroups: [
    {
      label: 'Use workspace protocol when developing local packages',
      dependencies: ['$LOCAL'],
      dependencyTypes: ['!local'],
      pinVersion: 'workspace:*',
    },
    {
      dependencies: ['@types/**'],
      dependencyTypes: ['!dev'],
      isBanned: true,
      label: '@types packages should only be under devDependencies',
    },
    {
      label: 'All Remix dependencies use versions the @myorg/remix package is using',
      dependencies: ['@remix-run/!(eslint-config)'],
      dependencyTypes: ['**'],
      snapTo: ['@myorg/remix'],
    },
  ],
}

module.exports = config

@JamieMason
Copy link
Owner

Nothing obvious stands out, my only theory is that maybe the @remix-run/!(eslint-config) glob isn't working as we expect. If you run syncpack list, is every @remix-run/** dependency in the same version group? or split across more than one?

@JamieMason JamieMason changed the title Adding entry to 'versionGroups' changes the result of 'Default Version Group' question(groups): help with configuring versionGroups May 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants