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

feat(version): Update 'version' field of package-lock.json #1998

Closed
larsgw opened this issue Mar 18, 2019 · 12 comments
Closed

feat(version): Update 'version' field of package-lock.json #1998

larsgw opened this issue Mar 18, 2019 · 12 comments

Comments

@larsgw
Copy link

larsgw commented Mar 18, 2019

Expected Behavior

I would expect lerna version to update the version field of package-lock.json files in packages that it updates the version of.

Current Behavior

Currently it seems like lerna version only updates package.json.

Solution

Update the version field in package-lock.json and npm-shrinkwrap.json. Edit: and yarn.lock I guess, and who knows what else, which also might explain why this isn't currently implemented.

Steps to Reproduce (for bugs)

  1. lerna init
  2. lerna create foo
  3. cd packages/foo && npm install && cd ../.. (generate package-lock.json)
  4. lerna version
  5. grep version packages/a/package{,-lock}.json
lerna.json

{
  "packages": [
    "packages/*"
  ],
  "version": "0.0.0"
}

Context

I haven't encountered any actual problems with it, but it just looks weird (and it's wrong too).

Your Environment

Executable Version
lerna --version 3.13.0
npm --version 6.9.0
yarn --version N/A
node --version v11.11.0
OS Version
NAME VERSION
Debian 8.2.0-14
@hugomallet
Copy link

Related : #1415

@larsgw
Copy link
Author

larsgw commented Mar 19, 2019

Oh, I hadn't found that one, sorry.

@revelt
Copy link
Contributor

revelt commented Apr 10, 2019

Should we close this issue? It seems #1415 had a working workaround...

To add 2p., I use Lerna to manage bunch of npm packages and lockfiles within npm packages are neither published to npm nor desired. I block lockfiles inside packages using .npmrc per-package, in each package's root file, single line inside package-lock=false. But I do keep the lockfile in the Lerna's root. With all this said, I don't care about lockfiles at all.

I guess it depends, what are those packages you use the Lerna for, if it's front-end pieces maybe lockfiles are desired.

@hugomallet
Copy link

The role of lerna is to maintain easily consistency in the monorepo.
If it breaks the consistency between package.json and package-lock.json i think it is a problem. Even more serious if it is committed and pushed automatically. My opinion is that it should not be resolved as a "workaround" only.

(discussing about the usage or utility of package-lock.json is not the purpose i think).

@revelt
Copy link
Contributor

revelt commented Apr 11, 2019

What if you did a npm install --package-lock before certain publishing/committing steps? It still seems to me it's safest if we left npm cli (or yarn) to create and manage their lockfiles.

@evocateur
Copy link
Member

It's simple enough, and we're already manipulating the package.json during lerna version. PRs welcome.

@lizardruss
Copy link

lizardruss commented May 3, 2019

I can offer some details for whoever might decide to work on a PR for this. There are two points in the lifecycle in which a package-lock.json might be updated. The first is version, which has already been discussed. The second is after publish, where freshly published dependencies now have a new integrity hash.

The publish work around that I've had success with is this script:

#! /bin/bash
lerna publish --yes --no-push
lerna exec -- npm install --package-lock-only --ignore-scripts --no-audit
git add **/package-lock.json
git commit --amend --no-edit
VERSION=`node -pe "require('$PWD/package.json').version;"`
git tag -f "v${VERSION}"
git push --follow-tags

A quick summary is that --no-push will make lerna skip the git tag and push during publish so that the script can update the package-lock.json files, amend the commit, tag, and finally push.

The above script only works for a project using fixed versions.

I would love to see this added to lerna, but I may not have time to submit a PR myself. I hope this helps someone who does!

@sthzg
Copy link

sthzg commented May 7, 2019

@lizardruss Thanks for sharing the snippet.

VERSION=`node -pe "require('$PWD/package.json').version;"`

Is the version populated in your root's package.json? I am trying to integrate the script but changed it to read lerna.json instead. Just curious if I am missing a/the point.

@lizardruss
Copy link

Yes, that part is just to read the version. You could use lerna.json for that too. I should also point out that my project isn’t using independent versions, so this snippet is written with that assumption.

@mikemimik
Copy link

It's simple enough, and we're already manipulating the package.json during lerna version. PRs welcome.

@evocateur I'm thinking of opening a pull-request for this feature. Is there any particular way you'd like to see this implemented. I've been fairly buried in the lerna code for the last 3 weeks and I think I have a good understanding of how it all connects together.

My first thought was to put this "feature" behind a flag, then update this method to also handle the package-lock file updates. Does that seem sane?

@mikemimik
Copy link

mikemimik commented Jul 4, 2019

@evocateur I didn't end up putting the feature behind a flag. Once I found where I thought would be a sane place to make the change, it just fell in naturally. There is a check to see if there is a package-lock.json file present, so I think it's safe.

@evocateur
Copy link
Member

v3.18.2

XDex added a commit to adobe/target-nodejs-sdk that referenced this issue Jan 21, 2022
This bug has been fixed in latest lerna, see lerna/lerna#1998
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants