syncpack icon indicating copy to clipboard operation
syncpack copied to clipboard

feat(core): sync `@type/xxx` packages

Open kevinxh opened this issue 1 year ago • 5 comments

Description

It would be nice if syncpack could sync the @type/xxx typescript declaration packages.

For example, we use syncpack fix-mismatches and upgrade one of our deps jsonwebtoken, but the types package @types/jsonwebtoken is left at older version.

Suggested Solution

Help Needed

kevinxh avatar Jun 05 '23 21:06 kevinxh

Thanks @kevinxh, it's a good idea. The closest thing today is https://jamiemason.github.io/syncpack/config/version-groups/pinned#pinversion-string but that's quite manual. I'll have a think how best to do this, some kind of aliasing feature or something.

JamieMason avatar Jun 05 '23 22:06 JamieMason

Opening this up to people for ideas on a nice way to handle this

  • it doesn't fit well with how minimatch is used in dependencies.
  • it probably wouldn't work as a new type of version group, because that would prevent you from applying other rules to any packages which also have types packages.
  • it might work as a new option on version groups, but it wouldn't make sense for every kind of version group.
  • maybe it could be a global setting, but someone would probably need to undo it in some version group somewhere anyway.
  • ...some other way?

JamieMason avatar Jun 25 '23 07:06 JamieMason

I'm new to syncpack. I got here trying to figure out why this didn't work:

 {
      label: 'Ensure react is all same version',
      packages: ['**'],
      dependencies: ['react', 'react-dom', '@types/react', '@types/react-dom'],
      dependencyTypes: ['!peer'],
      policy: 'sameRange',
    },

So maybe similar syntax since that's how it reads.

mctrafik avatar Dec 07 '23 08:12 mctrafik

I think I see what you're trying to do there @mctrafik, I think this is close to the pinVersion approach I was alluding to above. So to manually force those 4 packages to have the exact same version you could change that slightly to:

{
  "label": "Ensure react is all same version",
  "packages": ["**"],
  "dependencies": ["react", "react-dom", "@types/react", "@types/react-dom"],
  "dependencyTypes": ["!peer"],
  "pinVersion": "18.2.0"
}

I don't think this quite works in this scenario though as @types/** packages tend to have their own patch versions a lot of the time. This feature being discussed in this issue will help a lot, we just need to come up with an approach for it.

EDIT: I wonder if an approach something like this would work, so those packages are treated as being one.

{
  "label": "Ensure react is all same version",
  "packages": ["**"],
-  "dependencies": ["react", "react-dom", "@types/react", "@types/react-dom"],
+  "aliases": ["react", "react-dom", "@types/react", "@types/react-dom"],
  "dependencyTypes": ["!peer"],
  "pinVersion": "18.2.0"
}

JamieMason avatar Dec 07 '23 08:12 JamieMason

Dropping some $0.02 worth of context here.

The way @types/* versions are managed is documented here: https://github.com/DefinitelyTyped/DefinitelyTyped#how-do-definitely-typed-package-versions-relate-to-versions-of-the-corresponding-library

It's not exactly SemVer, but SemVer-ish.

Also, one caveat/edge case, is that the version of the @type/* package can be lagging behind the package that is being typed, in both the patch and minor versions. E.g. foo can be at 2.10.7, but the latest @types/foo can be at 2.9.3, for multiple reasons, such as no types have changed leading, and including, to [email protected], or no one bothered to update the types.

So all of these heuristics would need to be encoded in the logic.

moltar avatar Dec 23 '23 14:12 moltar