`package-lock.json` out of sync after version bump

[wSedlacek]

When using npm as a package manager the package-lock.json will become out of sync with the package.json after a version bump.

The package-lock.json contains a copy of the package.json used to generate it, so any change to the package.json requires a npm install to keep it in sync.

Having a hook to run a npm install && git add package-lock.json after the version bump but prior to the commit would solve this. Alternatively running the installPackagesTask exported from @nrwl/devkit possibly via an options flag would solve this.

Versions: Node v14, NPM v8

[greghopkins]

I am also experiencing this issue... After looking at the source, I see some options:

1. I am actually not versioning the "root" package anyway (it's marked private and doesn't get published)... I usually just remove version from the root package.json and, by extension, the root package-lock.json. I did this at first, but found that the root package.json is hard-coded into the standard-version bump files. Ignoring or skipping the root package.json could be made configurable and would solve for my use case.

2. More of the underlying standard-version configuration could be exposed. I even tried populating the standard-version .versionrc, but it looks like this configuration is only respected when you are using the standard-version CLI.

{
  "bumpFiles": [
    {
      "filename": "package-lock.json",
      "type": "json"
    }
  ]
}

3. Add root package-lock.json to the hard-coded list of bumpFiles... It would stand to reason that if you're bumping one, you should bump the other.

Number 3 seems like the "easiest".

[wSedlacek]

In my case I have locally installed projects that I am dog fooding via dependency entries like

 "@myworkspace/some-nx-plugin": "dist/libs/some-nx-plugin"

These each have an entry in the package-lock.json with not only their versions but the versions of their dependencies. To accurately update them after a version bump they need to have a full npm install run.

[greghopkins]

@wSedlacek - so it looks like your original suggestion of a config flag that would run installPackagesTask would meet both our needs. :) pretty please, @edbzn ?

[greghopkins]

@wSedlacek were you able to find a reasonable work-around? I'm at the point where I am having to add a step to my CD process that runs (push is set to false, obviously)

npm install
git add
git commit --amend
git push

And I really hate this 😢

[wSedlacek]

I am doing more or less the same thing.

nx version workspace
nx run-many --all --publish
rm -rf dist # To force npm to get the new versions of the packages that were published
npm install
git add -A
git commit -m "chore(deps): update package-lock.json [skip ci]"
git push origin main --follow-tags

I found that when I used --amend it would cause my next publish to run into issues with the git tags.

[greghopkins]

@wSedlacek

I found that when I used --amend it would cause my next publish to run into issues with the git tags.

Very good point - I need to check on that - when I amend the commit, I am losing the tag (since it's a different commit).

[greghopkins]

As a very unhappy workaround, this is currently functional for my team:

                    sh 'npm run version:prerelease'
                    sh '''
                        OLD_TAG=$(git tag --points-at HEAD)
                        npm install
                        git add ./package-lock.json
                        git commit --amend --no-edit
                        git tag -f $OLD_TAG
                    '''
                    sh '''
                        git push --follow-tags origin main
                        git push --tags
                    '''

[edbzn]

Hi, I never had this scenario where one of the projects within the workspace is defined as a dependency in the root package.json, and to be honest, I don't see why you would do that as Nx enforce the single-version policy by using path alias. Maybe am I missing something?

[wSedlacek]

I don't see why you would do that

In my case I am creating nx plugins within the same repository, and then using a tool we created called shipit to slice of certain parts of the workspace into other repositories. For example we have some projects that are open source so export those commits to a public repo for the public to view, but in the same private mono repo we have client projects and we may ship some of those to our clients.

The point being here is that after we ship a repo we need it to be a valid Nx workspace, which means the nx executors used in our projects use the package import ie @someorg/project:exeuctor rather than the relative file path ie ./dist/project:executor, this is because after shipping some projects they imports in the exported repos are converted to package.json entries rather than being local to the repo.

The bottom line is that each project needs to remain valid regardless of if an executor is installed via package.json or local to the repository and the best solution I could find for this was installing the local packages via package.json.

[greghopkins]

@edbzn I am using syncVersions and nothing within the workspace is marked as a dependency in the root... The issue is that, when using syncVersions, the root package.json version is updated (in addition to all the publishable libraries).

From workspace.json...

    "workspace": {
      "root": ".",
      "targets": {
        "version": {
          "executor": "@jscutlery/semver:version",
          "options": {
            "commitMessageFormat": "chore(${projectName}): release version ${version} [skip ci]",
            "push": false,
            "skipProjectChangelog": true,
            "skipRootChangelog": true,
            "syncVersions": true
          }
        }
      }
    }

Since my root is private, I'd rather that version not be updated at all, but if it's going to be, I think that the package-lock.json needs to be updated as well, otherwise they will forever be out of sync.

[Phault]

This is also relevant when npm workspaces are used, as the package-lock.json will contain each resolved workspace and their current version.