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

No package-lock.json? #1579

Closed
purplemana opened this Issue Jul 31, 2018 · 4 comments

Comments

Projects
None yet
2 participants
@purplemana
Copy link

commented Jul 31, 2018

Description / Steps to reproduce / Feature proposal

Didn't see a lockfile for safe npm installs. Are you tackling it in a different way?

@virkt25

This comment has been minimized.

Copy link
Contributor

commented Jul 31, 2018

Describe a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies. -- npm

We've disabled package-lock.json intentionally as the file is only a development aid and not ever published.

We believe in making sure we know when a dependency breaks us so we can fix it ASAP and disabling the lock file gives us that flexibility (CI/Devs can know) instead of being protected by a lock file while users installing a package might be breaking because of a minor / patch release.

Did you run into any issues with us not having a package-lock.json file?

@virkt25 virkt25 self-assigned this Jul 31, 2018

@purplemana

This comment has been minimized.

Copy link
Author

commented Aug 2, 2018

Nope, but while working with a large repos, I have seen too many failed dev installs due to broken third party packages which didn't follow semver as intended. So I was wondering how you guys are solving it.
I do appreciate your strategy. And when you do find an issue with a third party package, do you specify the exact last working version instead of ~?

@virkt25

This comment has been minimized.

Copy link
Contributor

commented Aug 2, 2018

Thanks for the question ... it's something we've seen happen many times where a dependency will break us. The most recent example of this comes from yeoman-test, see #1578 for more details.

Our approach to this really depends on what went wrong but the usual process is as follows:

  • If it's a quick upgrade then do so to get the builds green again ASAP (as we did with #1578 and other times in the past)
  • Work with the package owners to point out the breaking change and have them fix the issue ... or sometimes it can just be an accidental bug which we can help fix in the package ourselves.
  • Temporarily if needed we can pin the version as you suggested but I don't think we've done that yet with any given package -- except pinning Node to 10.0.0 on AppVeyor but hopefully that gets fixed soon.

It's not fun when we break because of a dependency but it's important for us to know and make sure we can keep using the latest versions (so update our code as needed) as latest versions can contain important bug fixes / security fixes.


@bajtos posted a great explanation on package-lock.json if you're interested in #1585 (comment)

I believe package-lock functionality was designed primarily for applications, where the developers wants to be in control of exactly which (deep) dependency versions are installed - at local dev time, at CI build server and finally in production too. It enables further useful features like npm ci (essentially a faster npm install).

The reason why we don't want to use package-lock in our modules is that as module authors, we want our users to always install the latest compatible version of all (deep) dependencies so that they can receive bug and security fixes without waiting for us to release a new version; and at the same time we want our CI to use the same version that our users will get (i.e. the latest).

In that light, I think it's actually a good thing that lb4 example in effect creates package-lock.json and (re)prints the message from npm.

It would be nice if there was a way how to distinguish between "application" examples and "module" examples, so that lb4 example can disable package-lock for modules (typically extensions like our log-extension) - but that's way beyond the scope of this pull request and may not be worth the effort.

@purplemana

This comment has been minimized.

Copy link
Author

commented Aug 3, 2018

Thanks for the detailed response, closing this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.