update package-lock.json with the newer version of the published package ([email protected])

[threepointone]

Whenever we do a changesets release, we have a problem where package-lock.json isn't in sync anymore. Specifically, because workspace definitions are also stored in this file, and we don't update the version numbers, there's a mismatch.

I would've just committed this directly to main, but I'm opening the PR to make this problem visible, and see if anyone has any suggestions for hot to fix this. Could the "Version Packages" PR generation process also run npm install at the root so package-lock.json also gets updated? Is this something the changesets team needs to fix?

[changeset-bot]

⚠️ No Changeset found

Latest commit: 49248b1

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[threepointone]

cc @Andarist am I missing something here? Is this a common problem with changesets? Thank you!

[petebacondarwin]

I think this is a result of our use of npm workspaces. See npm/cli#3756

[petebacondarwin]

Could we do something along the lines of

          version: npx changeset version && git commit -a -m"update package-lock file"

release.yml github workflow?

[threepointone]

Yeah, but changesets is built for workspaces, so I'd imagine they'd have a "solution". I don't think npx changeset version changes package-lock.json either (I could be wrong?)

[Andarist]

@threepointone it appears that this is currently a known problem with Changesets: changesets/changesets#421

I didn't run into this myself cause Yarn Classic (which is still my primary package manager, old habits) doesn't keep this information in the lockfile. But yes - I believe that this should be handled by Changesets cause it's not good that the user runs into problems like this. I think there are 3 solutions here:

• regenerate lockfile with the updated information using the appropriate CLI. I really, really hope that there is a command that would only do this and nothing beyond that - q: how did you update those versions here?
• regenerate lockfile with the updated information manually
• use npm version (or equivalent) to update the version of each workspace, seems somewhat heavy as we'd have to run this multiple times - manipulating package.json files is a nice and simple approach. I assume that a command like this updates the information in the lockfile. A note is that by default git commits and tags are created with npm version so we'd have to use CLI flags to disable this behavior.

For the time being, I would recommend patching this with a script called after changeset version on your end and hopefully the need for this script will be gone with time (I won't have time to work on this right now, any help appreciated!)

[petebacondarwin]

@Andarist - thanks for the quick response!

q: how did you update those versions here?

You just run npm i in the root of the project.

[petebacondarwin]

use npm version (or equivalent)

From npm/cli#3756 is looks like this is also a problem with npm version.

[petebacondarwin]

I have created #212 to workaround this for the time-being.
The fix for changesets is a little more involved since one must use a different command to update the lock-file depending upon which package manager is being used.

[Andarist]

From npm/cli#3756 is looks like this is also a problem with npm version.

I won't lie... that this won't work crossed my mind 😂

You just run npm i in the root of the project.

One concern that I have with this is that at least Yarn Classic can update the lock when running yarn install (if the current lock doesn't match the declared deps, so when the "structure" got corrupted~) unless yarn install --frozen-lockfile is used. I think that we (Changesets) shouldn't affect anything beyond those versions of local workspaces - if the structure is corrupted then that should be fixed separately. Maybe there is a way to call npm i in a way that would only update those versions without affecting anything else but I would have to research this more. In a way - maybe tweaking the lock file "manually" would actually be the easiest (at the expense of having to learn how to tweak all of the existing formats 😢 )