This repository has been archived by the owner. It is now read-only.

spec: Describe npm-shrinkwrap.json and package-lock.json #16441

Closed
wants to merge 2 commits into
base: latest
from

Conversation

@iarna
Member

iarna commented Apr 25, 2017

Here is my proposal for how shrinkwraps in npm@5 will work. We will also be introducing a new file, package-lock.json that will fill the same role as npm-shrinkwrap.json in projects that don't otherwise have a shrinkwrap.

The TLDR is:

You'll use an npm-shrinkwrap.json if you want to publish it so that users of your module will consume it.
Otherwise you'll use a package-lock.json. package-lock.json files will never be published but are suitable for checking into git.

This is open for feedback for the next two weeks. (I mean, we'll take feedback whenever, but it won't be immediately actionable beyond that.)

@iarna iarna added the in-progress label Apr 25, 2017

@felixrieseberg

This comment has been minimized.

Show comment
Hide comment
@felixrieseberg

felixrieseberg Apr 25, 2017

Contributor

Hey Rebecca, fantastic effort 👏 I'm so happy you're putting some focus on shrinkwraps, they're core to releases we make. Thank you!

One thing I'd like to call out: Cross-platform shrinkwraps. You cover that with "All optional dependencies should be included even if they're uninstallable on the current platform", but I'd love to see this be a reliable feature of shrinkwraps.

npm is possibly the best cross-platform installation tool available right now. At Slack and in other projects, I use shrinkwraps to describe the exact dependency tree of a cross-platform project at compilation time. We currently merge shrinkwraps generated on each platform by hand, but we'd love to be able to generate the "one true master shrinkwrap" automatically.

Contributor

felixrieseberg commented Apr 25, 2017

Hey Rebecca, fantastic effort 👏 I'm so happy you're putting some focus on shrinkwraps, they're core to releases we make. Thank you!

One thing I'd like to call out: Cross-platform shrinkwraps. You cover that with "All optional dependencies should be included even if they're uninstallable on the current platform", but I'd love to see this be a reliable feature of shrinkwraps.

npm is possibly the best cross-platform installation tool available right now. At Slack and in other projects, I use shrinkwraps to describe the exact dependency tree of a cross-platform project at compilation time. We currently merge shrinkwraps generated on each platform by hand, but we'd love to be able to generate the "one true master shrinkwrap" automatically.

@zkat

This comment has been minimized.

Show comment
Hide comment
@zkat

zkat Apr 25, 2017

Member

@felixrieseberg This spec also covers the shrinkwrap behavior. The difference between package-lock.json and npm-shrinkwrap.json is that the latter is meant for publication, and the former is meant for devs to commit. The rest is the same (modulo the fact that this new version of the lockfile has different fields -- older npms will still be able to install with shrinkwraps generated by this though)

Member

zkat commented Apr 25, 2017

@felixrieseberg This spec also covers the shrinkwrap behavior. The difference between package-lock.json and npm-shrinkwrap.json is that the latter is meant for publication, and the former is meant for devs to commit. The rest is the same (modulo the fact that this new version of the lockfile has different fields -- older npms will still be able to install with shrinkwraps generated by this though)

@vinkla

This comment has been minimized.

Show comment
Hide comment
@vinkla

vinkla Apr 25, 2017

Great idea 🎉 I think this will make it easier for newcomers to understand what the lock file is.

We will also be introducing a new file, package-lock.json that will fill the same role as npm-shrinkwrap.json in projects that don't otherwise have a shrinkwrap.

What about naming the lock file to package.lock similar to how Composer and Yarn handles lock files? In my opinion it would make it even easier to understand.

package.json
package.lock

Reference in the Composer documentation: https://getcomposer.org/doc/01-basic-usage.md#installing-with-composer-lock

vinkla commented Apr 25, 2017

Great idea 🎉 I think this will make it easier for newcomers to understand what the lock file is.

We will also be introducing a new file, package-lock.json that will fill the same role as npm-shrinkwrap.json in projects that don't otherwise have a shrinkwrap.

What about naming the lock file to package.lock similar to how Composer and Yarn handles lock files? In my opinion it would make it even easier to understand.

package.json
package.lock

Reference in the Composer documentation: https://getcomposer.org/doc/01-basic-usage.md#installing-with-composer-lock

@iamstarkov

This comment has been minimized.

Show comment
Hide comment
@iamstarkov

iamstarkov Apr 25, 2017

i know @zkochan worked hard to get reliable lock file for pnpm. he might has some input

iamstarkov commented Apr 25, 2017

i know @zkochan worked hard to get reliable lock file for pnpm. he might has some input

@iamstarkov

This comment has been minimized.

Show comment
Hide comment
@iamstarkov

iamstarkov Apr 25, 2017

@vinkla package.lock seems like a nice filename

iamstarkov commented Apr 25, 2017

@vinkla package.lock seems like a nice filename

@zkat

This comment has been minimized.

Show comment
Hide comment
@zkat

zkat Apr 25, 2017

Member

@vinkla The current name is clearer about the file format. require('./package-lock.json') will give you a parsed JSON object with this. Other tools that look at the extension will work unaltered (for example, webpack, editors, etc).

(I don't really see much of a difference between package.lock and package-lock.json as far as clarity goes. It seems to me like it would be pretty minor, and unlikely to be significant enough to sacrifice the occasional JSON tooling convenience.)

Member

zkat commented Apr 25, 2017

@vinkla The current name is clearer about the file format. require('./package-lock.json') will give you a parsed JSON object with this. Other tools that look at the extension will work unaltered (for example, webpack, editors, etc).

(I don't really see much of a difference between package.lock and package-lock.json as far as clarity goes. It seems to me like it would be pretty minor, and unlikely to be significant enough to sacrifice the occasional JSON tooling convenience.)

@zkat zkat referenced this pull request Apr 25, 2017

Closed

release: npm@5.0.0 #16244

16 of 24 tasks complete
@vinkla

This comment has been minimized.

Show comment
Hide comment
@vinkla

vinkla Apr 25, 2017

@zkat I understand the file format issue and I agree .json makes it clearer what kind of content the file contains. Though, in my opinion it is clearer that the file ending with lock locks the dependencies in the package.json file. It also makes the file tree look clean.

package.json
package.lock

For newcomers, I think package.json and package-lock.json will take longer to connect than what package.json and package.lock would.

It would be cool if we were to sync the naming convention with Yarn and Composer. Then developers getting started with npm coming from another package manager such as Yarn or Composer would be familiar with the lock file extension. This would also work the other way around.

vinkla commented Apr 25, 2017

@zkat I understand the file format issue and I agree .json makes it clearer what kind of content the file contains. Though, in my opinion it is clearer that the file ending with lock locks the dependencies in the package.json file. It also makes the file tree look clean.

package.json
package.lock

For newcomers, I think package.json and package-lock.json will take longer to connect than what package.json and package.lock would.

It would be cool if we were to sync the naming convention with Yarn and Composer. Then developers getting started with npm coming from another package manager such as Yarn or Composer would be familiar with the lock file extension. This would also work the other way around.

@iarna

This comment has been minimized.

Show comment
Hide comment
@iarna

iarna Apr 25, 2017

Member

@felixrieseberg Regarding cross platformness, I'll make sure it's clearer, but yes, ALL optional dependencies, ALL dev dependencies should be in lock/shrinkwrap files even if you installed with --no-optional and --only=production.

Member

iarna commented Apr 25, 2017

@felixrieseberg Regarding cross platformness, I'll make sure it's clearer, but yes, ALL optional dependencies, ALL dev dependencies should be in lock/shrinkwrap files even if you installed with --no-optional and --only=production.

@jesstelford

Excellent stuff - looking forward to it!

@zkochan

This comment has been minimized.

Show comment
Hide comment
@zkochan

zkochan Apr 25, 2017

What about some of the configurations found in npmrc?

Shouldn't they be included in the lock file? I mean things like: no-bin-links, ignore-scripts. Probably there are more. Configs that can change the way dependencies are installed

zkochan commented Apr 25, 2017

What about some of the configurations found in npmrc?

Shouldn't they be included in the lock file? I mean things like: no-bin-links, ignore-scripts. Probably there are more. Configs that can change the way dependencies are installed

@iarna

This comment has been minimized.

Show comment
Hide comment
@iarna

iarna Apr 26, 2017

Member

@zkochan No, I believe those belong in a project-local .npmrc. There is one that that I think does belong in a lock/shrinkwrap and that's node's preserve-symlinks (env: NODE_PRESERVE_SYMLINKS).

Member

iarna commented Apr 26, 2017

@zkochan No, I believe those belong in a project-local .npmrc. There is one that that I think does belong in a lock/shrinkwrap and that's node's preserve-symlinks (env: NODE_PRESERVE_SYMLINKS).

@novemberborn

This comment has been minimized.

Show comment
Hide comment
@novemberborn

novemberborn Apr 26, 2017

How would one update a package-lock.json if new dependencies were added by manually editing package.json? Presumably running npm install would install those dependencies, but it won't update package-lock.json.

novemberborn commented Apr 26, 2017

How would one update a package-lock.json if new dependencies were added by manually editing package.json? Presumably running npm install would install those dependencies, but it won't update package-lock.json.

Show outdated Hide outdated spec/shrinkwrap-and-lock.md
Show outdated Hide outdated spec/shrinkwrap-and-lock.md
Show outdated Hide outdated spec/shrinkwrap-and-lock.md
@iarna

This comment has been minimized.

Show comment
Hide comment
@iarna

iarna Apr 26, 2017

Member

@novemberborn You'll note that the package-lock has a integrity hash generated from the package.json. Ah, I didn't mention that when describing install semantics, I'll correct that.

Member

iarna commented Apr 26, 2017

@novemberborn You'll note that the package-lock has a integrity hash generated from the package.json. Ah, I didn't mention that when describing install semantics, I'll correct that.

@legodude17

Fast installs for everyone!

Show outdated Hide outdated spec/shrinkwrap-and-lock.md
Show outdated Hide outdated spec/shrinkwrap-and-lock.md
Show outdated Hide outdated spec/shrinkwrap-and-lock.md
Show outdated Hide outdated spec/shrinkwrap-and-lock.md
Show outdated Hide outdated spec/shrinkwrap-and-lock.md
Show outdated Hide outdated spec/shrinkwrap-and-lock.md
Show outdated Hide outdated spec/shrinkwrap-and-lock.md
Show outdated Hide outdated spec/shrinkwrap-and-lock.md
Show outdated Hide outdated spec/shrinkwrap-and-lock.md
Show outdated Hide outdated spec/shrinkwrap-and-lock.md
@novemberborn

This comment has been minimized.

Show comment
Hide comment
@novemberborn

novemberborn Apr 27, 2017

@iarna

You'll note that the package-lock has a integrity hash generated from the package.json. Ah, I didn't mention that when describing install semantics, I'll correct that.

Sure. Once it's out of sync though, how would I update the package-lock.json file?

novemberborn commented Apr 27, 2017

@iarna

You'll note that the package-lock has a integrity hash generated from the package.json. Ah, I didn't mention that when describing install semantics, I'll correct that.

Sure. Once it's out of sync though, how would I update the package-lock.json file?

@indexzero

This comment has been minimized.

Show comment
Hide comment
@indexzero

indexzero Apr 27, 2017

Contributor

🥇 well articulated & sensible. Really happy to see npm moving towards supporting lockfiles, but also introducing the semantics that yarn lacks. That is differentiating between publishable lockfiles (in this case npm-shrinkwrap.json) and non-publishable lockfiles for performance optimization of the average case (package-lock.json).

Contributor

indexzero commented Apr 27, 2017

🥇 well articulated & sensible. Really happy to see npm moving towards supporting lockfiles, but also introducing the semantics that yarn lacks. That is differentiating between publishable lockfiles (in this case npm-shrinkwrap.json) and non-publishable lockfiles for performance optimization of the average case (package-lock.json).

@zkat

Added some comments around git and bundle deps stuff

Show outdated Hide outdated spec/shrinkwrap-and-lock.md
Show outdated Hide outdated spec/shrinkwrap-and-lock.md

zkat added a commit that referenced this pull request May 2, 2017

feat(lockfile): add package-lock.json support
This implements #16441 as well as the auto-save behavior it needs in order to be kept up to date.
@alloy

This comment has been minimized.

Show comment
Hide comment
@alloy

alloy May 2, 2017

Has there been any thought given into making the lockfile shareable with yarn?

alloy commented May 2, 2017

Has there been any thought given into making the lockfile shareable with yarn?

@zkat

This comment has been minimized.

Show comment
Hide comment
@zkat

zkat May 2, 2017

Member

@alloy Yes. We honestly believe that this package-lock.json syntax can be used (and written) by yarn. The goal here is that different people on the same team can use different package managers with their own advantages, but all would be able to generate identical trees, regardless of which tool you use, or even which version of the tool you use.

This format defines a specific tree -- something that all npm-compatible package managers would need to have as a data structure internally somewhere. This format also includes the tarball checksum, the resolved field to get the exact version remotely, the version #. The tree structure defines which node depends on what. I believe all current package managers with lockfiles would be able to do their required work with this information. There's also an allowance for extending stuff with package manager-specific metadata that they could use for this or that.

Member

zkat commented May 2, 2017

@alloy Yes. We honestly believe that this package-lock.json syntax can be used (and written) by yarn. The goal here is that different people on the same team can use different package managers with their own advantages, but all would be able to generate identical trees, regardless of which tool you use, or even which version of the tool you use.

This format defines a specific tree -- something that all npm-compatible package managers would need to have as a data structure internally somewhere. This format also includes the tarball checksum, the resolved field to get the exact version remotely, the version #. The tree structure defines which node depends on what. I believe all current package managers with lockfiles would be able to do their required work with this information. There's also an allowance for extending stuff with package manager-specific metadata that they could use for this or that.

@alloy

This comment has been minimized.

Show comment
Hide comment
@alloy

alloy May 2, 2017

Awesome, thanks for the info and great stuff 👏

alloy commented May 2, 2017

Awesome, thanks for the info and great stuff 👏

@zkat

This comment has been minimized.

Show comment
Hide comment
@zkat

zkat May 2, 2017

Member

(if it's not clear yet, it's really important to us that we don't end up with a lockdown situation in any direction: much like npm goes out of its way to support alternative registries, and the registry allows non-npm-cli clients to connect to it, and we document all our APIs. We'll keep doing our best to encourage the entire ecosystem's growth. In the end, npm is here for the sake of the community)

Member

zkat commented May 2, 2017

(if it's not clear yet, it's really important to us that we don't end up with a lockdown situation in any direction: much like npm goes out of its way to support alternative registries, and the registry allows non-npm-cli clients to connect to it, and we document all our APIs. We'll keep doing our best to encourage the entire ecosystem's growth. In the end, npm is here for the sake of the community)

@cpojer

This comment has been minimized.

Show comment
Hide comment
@cpojer

cpojer May 2, 2017

One issue we ran into at Facebook before building Yarn was that npm-shrinkwrap wasn't stable and small changes often produced 10,000+ line changes in the shrinkwrap file. I would suggest sorting the package-lock.json file using json-stable-stringify and adding that to the spec.

Further, we noticed people weren't ever looking at shrinkwrap changes, which is what lead us to create a separate, human-readable format for yarn's lockfiles. Can you elaborate on why you are suggesting to use JSON as the preferred format? Thanks!

cpojer commented May 2, 2017

One issue we ran into at Facebook before building Yarn was that npm-shrinkwrap wasn't stable and small changes often produced 10,000+ line changes in the shrinkwrap file. I would suggest sorting the package-lock.json file using json-stable-stringify and adding that to the spec.

Further, we noticed people weren't ever looking at shrinkwrap changes, which is what lead us to create a separate, human-readable format for yarn's lockfiles. Can you elaborate on why you are suggesting to use JSON as the preferred format? Thanks!

@zkat

This comment has been minimized.

Show comment
Hide comment
@zkat

zkat May 2, 2017

Member

@cpojer Hi!

  1. package-lock.json is already sorted. Specifying that in the spec for clarity is a great idea.

  2. A huge reason for npm-shrinkwrap giving you conflicts and nonsense diffs was the from field, as well as inconsistencies in how version was written (because we'd end up writing resolved into version. You can see the sorts of diffs that you get now here:

screen shot 2017-05-02 at 11 14 05

  1. JSON is a format that's natively readable by node.js, and shares a format with package.json. With the simplified, standardized fields, this would bring the JSON format to the same information level as something like yarn.lock. For something that is intended to be used across any package manager, I think it's the right thing to not require a particular non-built-in format. Furthermore, package-lock.json, through its nesting, defines a specific tree to build -- my understanding is that formats like yarn.lock require a specific treebuilding algorithm (which can change between versions!) to build identical trees. In contrast, someone could symlink package-lock.json to npm-shrinkwrap.json for a CI build of their library using npm@2, and they'll get the exact same tree that yarn may have generated. It means that you can use yarn's trees in npm! :)
Member

zkat commented May 2, 2017

@cpojer Hi!

  1. package-lock.json is already sorted. Specifying that in the spec for clarity is a great idea.

  2. A huge reason for npm-shrinkwrap giving you conflicts and nonsense diffs was the from field, as well as inconsistencies in how version was written (because we'd end up writing resolved into version. You can see the sorts of diffs that you get now here:

screen shot 2017-05-02 at 11 14 05

  1. JSON is a format that's natively readable by node.js, and shares a format with package.json. With the simplified, standardized fields, this would bring the JSON format to the same information level as something like yarn.lock. For something that is intended to be used across any package manager, I think it's the right thing to not require a particular non-built-in format. Furthermore, package-lock.json, through its nesting, defines a specific tree to build -- my understanding is that formats like yarn.lock require a specific treebuilding algorithm (which can change between versions!) to build identical trees. In contrast, someone could symlink package-lock.json to npm-shrinkwrap.json for a CI build of their library using npm@2, and they'll get the exact same tree that yarn may have generated. It means that you can use yarn's trees in npm! :)
@iarna

This comment has been minimized.

Show comment
Hide comment
@iarna

iarna May 2, 2017

Member

One issue we ran into at Facebook before building Yarn was that npm-shrinkwrap wasn't stable and small changes often produced 10,000+ line changes in the shrinkwrap file. I would suggest sorting the package-lock.json file using json-stable-stringify and adding that to the spec.

npm-shrinkwrap has been sorted and its structure stable since npm@3. The primary source of the churn was the from field. The secondary one is folks running git pull and then npm shrinkwrap without an intervening npm install (which was was possible when the changes had been semver compatible). (The latter will be addressed by changes to the implementation within npm.)

Basically, none of the complaints I've seen about npm-shrinkwrap.json were related to the file format itself.

The main reason we didn't consider yarn.lock is that it does not actually describe a physical tree and the shape of the installed tree can, will and has changed between implementations and versions of implementations. That you will always get exactly the same tree is a guarantee we wanted to be able to make and it's not one that yarn.lock has any facility to do without also locking down tree layout algorithms in a way I would consider harmful.

Edit: Ah, I see managed to write neigh the same thing as @zkat =D

Member

iarna commented May 2, 2017

One issue we ran into at Facebook before building Yarn was that npm-shrinkwrap wasn't stable and small changes often produced 10,000+ line changes in the shrinkwrap file. I would suggest sorting the package-lock.json file using json-stable-stringify and adding that to the spec.

npm-shrinkwrap has been sorted and its structure stable since npm@3. The primary source of the churn was the from field. The secondary one is folks running git pull and then npm shrinkwrap without an intervening npm install (which was was possible when the changes had been semver compatible). (The latter will be addressed by changes to the implementation within npm.)

Basically, none of the complaints I've seen about npm-shrinkwrap.json were related to the file format itself.

The main reason we didn't consider yarn.lock is that it does not actually describe a physical tree and the shape of the installed tree can, will and has changed between implementations and versions of implementations. That you will always get exactly the same tree is a guarantee we wanted to be able to make and it's not one that yarn.lock has any facility to do without also locking down tree layout algorithms in a way I would consider harmful.

Edit: Ah, I see managed to write neigh the same thing as @zkat =D

@pmuellr

This comment has been minimized.

Show comment
Hide comment
@pmuellr

pmuellr May 3, 2017

This format defines a specific tree ... The tree structure defines which node depends on what.

Looking only at GH/zkat/cacache/package-lock.json, and not the code, have some questions.

It looks like the lock file contents mirror the directories npm creates during an npm install - eg, flattened, with same package/different versions handled via deeper directories in the packages that depend on them. Eg, the different versions of wordwrap used in the referenced lock file.

This seems like an implementation detail. Has any thought been given to showing the actual dep structure instead? More like the output of npm ls --json. An "ideal" directory tree could be calculated from that, and having the structure would be nice for dependency analysis tooling. As an example, if you'd like to do some kind of interesting dependency analysis of a package, and had the lock file with that structure, you could just read it. Without the structure, you'd have to start at the package file (or lock file), then get deps for dependent packages from npm.

As an example of dep analysis, see https://github.com/pmuellr/npmls2dg - you can drag'n'drop the output of npm ls --json on the page and get deps graphed. If the lock file had the dep structure, you could drop the lock file, instead of having to run npm ls --json at all. Having the lock files checked in means all this dep info would be available directly in GH without having to touch an npm registry at all.

The resulting file would be larger than the current lock file, as there would be duplication information in the tree. I'm not sure in the end the size matters that much, but might be interesting to see if a hybrid structure would allow for some cost savings - eg, store a separate map of package/version => info, and ref the dependencies as just the package/version key of that map, sort of thing.

pmuellr commented May 3, 2017

This format defines a specific tree ... The tree structure defines which node depends on what.

Looking only at GH/zkat/cacache/package-lock.json, and not the code, have some questions.

It looks like the lock file contents mirror the directories npm creates during an npm install - eg, flattened, with same package/different versions handled via deeper directories in the packages that depend on them. Eg, the different versions of wordwrap used in the referenced lock file.

This seems like an implementation detail. Has any thought been given to showing the actual dep structure instead? More like the output of npm ls --json. An "ideal" directory tree could be calculated from that, and having the structure would be nice for dependency analysis tooling. As an example, if you'd like to do some kind of interesting dependency analysis of a package, and had the lock file with that structure, you could just read it. Without the structure, you'd have to start at the package file (or lock file), then get deps for dependent packages from npm.

As an example of dep analysis, see https://github.com/pmuellr/npmls2dg - you can drag'n'drop the output of npm ls --json on the page and get deps graphed. If the lock file had the dep structure, you could drop the lock file, instead of having to run npm ls --json at all. Having the lock files checked in means all this dep info would be available directly in GH without having to touch an npm registry at all.

The resulting file would be larger than the current lock file, as there would be duplication information in the tree. I'm not sure in the end the size matters that much, but might be interesting to see if a hybrid structure would allow for some cost savings - eg, store a separate map of package/version => info, and ref the dependencies as just the package/version key of that map, sort of thing.

@zkat

This comment has been minimized.

Show comment
Hide comment
@zkat

zkat May 3, 2017

Member

@pmuellr it's not an implementation detail in practice: the actual physical arrangement of the tree has a huge effect on actual behavior and is one of the biggest reasons for having a lockfile (aside from just being more specific about versions). That's why it's important to have the final structure meant for the disk. Different algorithms will flatten the tree using different heuristics (if any!) so this matters.

Member

zkat commented May 3, 2017

@pmuellr it's not an implementation detail in practice: the actual physical arrangement of the tree has a huge effect on actual behavior and is one of the biggest reasons for having a lockfile (aside from just being more specific about versions). That's why it's important to have the final structure meant for the disk. Different algorithms will flatten the tree using different heuristics (if any!) so this matters.

@pmuellr

This comment has been minimized.

Show comment
Hide comment
@pmuellr

pmuellr May 3, 2017

the actual physical arrangement of the tree has a huge effect on actual behavior and is one of the biggest reasons for having a lockfile

I'm very likely missing an important piece here, perhaps what "actual behavior" means. Seems like given the deps structure from npm ls --json, you can calculate a disk structure (or structures, you can of course imagine multiple strategies for this - I want npm2 style! :-) ). Maybe that's not enough tho.

I guess I basically just feel like this may be a missed opportunity at having some really interesting dep information persisted with projects as a file - info that you can only get today via server interaction. The info is calculated, then tossed in the bit bucket. Sad! (heh)

Could there be some way of doing both? Maybe serialize the dep structure, but add a property for the resultant disk path it resides at?

pmuellr commented May 3, 2017

the actual physical arrangement of the tree has a huge effect on actual behavior and is one of the biggest reasons for having a lockfile

I'm very likely missing an important piece here, perhaps what "actual behavior" means. Seems like given the deps structure from npm ls --json, you can calculate a disk structure (or structures, you can of course imagine multiple strategies for this - I want npm2 style! :-) ). Maybe that's not enough tho.

I guess I basically just feel like this may be a missed opportunity at having some really interesting dep information persisted with projects as a file - info that you can only get today via server interaction. The info is calculated, then tossed in the bit bucket. Sad! (heh)

Could there be some way of doing both? Maybe serialize the dep structure, but add a property for the resultant disk path it resides at?

Mithgol added a commit to Mithgol/fiunis that referenced this pull request May 29, 2017

Mithgol added a commit to Mithgol/mithrilsql that referenced this pull request May 29, 2017

Mithgol added a commit to Mithgol/node-abstract-syntax-tree that referenced this pull request May 29, 2017

Mithgol added a commit to Mithgol/node-ciel that referenced this pull request May 29, 2017

Mithgol added a commit to Mithgol/node-fido2twi that referenced this pull request May 29, 2017

Mithgol added a commit to Mithgol/node-fidoconfig that referenced this pull request May 29, 2017

@monolithed

This comment has been minimized.

Show comment
Hide comment
@monolithed

monolithed May 30, 2017

I want to understand what the lock file is, but I can't while we cannot update the package-lock.json file when new dependencies were added by manually editing package.json. it's weird.

monolithed commented May 30, 2017

I want to understand what the lock file is, but I can't while we cannot update the package-lock.json file when new dependencies were added by manually editing package.json. it's weird.

Mithgol added a commit to Mithgol/node-fidonet-jam that referenced this pull request May 30, 2017

Mithgol added a commit to Mithgol/node-fidonet-nodelist that referenced this pull request May 30, 2017

Mithgol added a commit to Mithgol/node-find-msgid-in-file that referenced this pull request May 30, 2017

Mithgol added a commit to Mithgol/node-ftp-fileecho-list that referenced this pull request May 30, 2017

@zkochan

This comment has been minimized.

Show comment
Hide comment
@zkochan

zkochan May 30, 2017

I think it would be nice to be able to detect which dependencies cannot be installed on the current system using just the lockfile. Currently, the package.json has to be downloaded in order to check the engines field. Having the engines field in the lockfiles would save us a few redundant HTTP requests.

What do you think?

It may be valuable info for code reviews as well

zkochan commented May 30, 2017

I think it would be nice to be able to detect which dependencies cannot be installed on the current system using just the lockfile. Currently, the package.json has to be downloaded in order to check the engines field. Having the engines field in the lockfiles would save us a few redundant HTTP requests.

What do you think?

It may be valuable info for code reviews as well

Mithgol added a commit to Mithgol/node-gamayun that referenced this pull request May 30, 2017

Mithgol added a commit to Mithgol/node-large-split that referenced this pull request May 30, 2017

Mithgol added a commit to Mithgol/node-truncate-escaped-html that referenced this pull request May 30, 2017

Mithgol added a commit to Mithgol/node-twi2fido that referenced this pull request May 30, 2017

@zkat

This comment has been minimized.

Show comment
Hide comment
@zkat

zkat May 30, 2017

Member

@zkochan part of the issue is that the definition of "failed optional dep" is literally "tried to install it and it failed". The engines field has always been an FYI and we can't really treat it as normative, lest a lot of other stuff break, I think. /cc @iarna cause I'm pretty sure that's right.

Member

zkat commented May 30, 2017

@zkochan part of the issue is that the definition of "failed optional dep" is literally "tried to install it and it failed". The engines field has always been an FYI and we can't really treat it as normative, lest a lot of other stuff break, I think. /cc @iarna cause I'm pretty sure that's right.

Mithgol added a commit to Mithgol/node-unsquish that referenced this pull request May 31, 2017

Mithgol added a commit to Mithgol/node-uue that referenced this pull request May 31, 2017

Mithgol added a commit to Mithgol/node-uue2ipfs that referenced this pull request May 31, 2017

Mithgol added a commit to Mithgol/node-webbbs that referenced this pull request May 31, 2017

Mithgol added a commit to Mithgol/npmtree that referenced this pull request May 31, 2017

Mithgol added a commit to Mithgol/phido that referenced this pull request May 31, 2017

Mithgol added a commit to Mithgol/rss2fido that referenced this pull request Jun 1, 2017

Mithgol added a commit to Mithgol/rules-fe2hpt that referenced this pull request Jun 1, 2017

Mithgol added a commit to Mithgol/shee2arr that referenced this pull request Jun 1, 2017

@zkochan

This comment has been minimized.

Show comment
Hide comment
@zkochan

zkochan Jun 2, 2017

@zkat unless engine-strict is set to true

If set to true, then npm will stubbornly refuse to install (or even consider installing) any package that claims to not be compatible with the current Node.js version.

zkochan commented Jun 2, 2017

@zkat unless engine-strict is set to true

If set to true, then npm will stubbornly refuse to install (or even consider installing) any package that claims to not be compatible with the current Node.js version.

@isaacs

This comment has been minimized.

Show comment
Hide comment
@isaacs

isaacs Jun 2, 2017

Member

It's well after the time for comments on this particular aspect of the bikeshed, and what I wanted already happened, but .lock as a file extension tells me it's a file system mutex lock. I know yarn and gem don't use it that way, but I've interacted with many programs over the years that do. (For example, this is what a .lock file in an npm <4 cache is.)

The .json extension says "this contains meaningful data".

Member

isaacs commented Jun 2, 2017

It's well after the time for comments on this particular aspect of the bikeshed, and what I wanted already happened, but .lock as a file extension tells me it's a file system mutex lock. I know yarn and gem don't use it that way, but I've interacted with many programs over the years that do. (For example, this is what a .lock file in an npm <4 cache is.)

The .json extension says "this contains meaningful data".

@gauravmuk

This comment has been minimized.

Show comment
Hide comment
@gauravmuk

gauravmuk Jun 15, 2017

Is there any way that I can not generate package-lock.json every time on npm install with npm@5?

EDIT: got the answer, --no-package-lock

gauravmuk commented Jun 15, 2017

Is there any way that I can not generate package-lock.json every time on npm install with npm@5?

EDIT: got the answer, --no-package-lock

This is a
[subresource integrity](https://w3c.github.io/webappsec/specs/subresourceintegrity/)
value created from the `pacakge.json`. No preprocessing of the

This comment has been minimized.

@saoirse-zee

saoirse-zee Jun 27, 2017

Typo: pacakge --> package :)

@saoirse-zee

saoirse-zee Jun 27, 2017

Typo: pacakge --> package :)

@zkat

This comment has been minimized.

Show comment
Hide comment
@zkat

zkat Jun 29, 2017

Member

This has been merged 👍

Member

zkat commented Jun 29, 2017

This has been merged 👍

@zkat zkat closed this Jun 29, 2017

zkat added a commit that referenced this pull request Jul 5, 2017

@felixfbecker felixfbecker referenced this pull request Jul 7, 2017

Closed

Support NPM5 #30134

@iarna iarna deleted the iarna/shrinkwrap-rfc branch Feb 1, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.