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

In shrinkwrap.yaml deps of deps can be locked to a version which doesn't satisfy the package.json semver #634

Closed
vjpr opened this issue Feb 22, 2017 · 11 comments

Comments

@vjpr
Copy link
Contributor

vjpr commented Feb 22, 2017

I encountered an issue where lodash@3 was saved in the shrinkwrap.yaml for a module that required lodash@4. I had to remove the shrinkwrap.yaml file to fix it.

How does pnpm make use of the shrinkwrap file?

Does it ensure that the deps of deps satisfies the parent deps package.json dependencies semver?

@zkochan
Copy link
Member

zkochan commented Feb 22, 2017

why should it satisfy the parent deps package.json? it should satisfy only the package.json which requires the dependency.

I encountered an issue where lodash@3 was saved in the shrinkwrap.yaml for a module that required lodash@4. I had to remove the shrinkwrap.yaml file to fix it.

steps to reproduce would be helpful. If it happens, it is a bug for sure

@vjpr
Copy link
Contributor Author

vjpr commented Feb 22, 2017

why should it satisfy the parent deps package.json? it should satisfy only the package.json which requires the dependency.

That's what I meant.

I will try to reproduce it in a small project.

@vjpr
Copy link
Contributor Author

vjpr commented Mar 3, 2017

Reproduced.

pnpm v0.58.0

npm init -y
pnpm i -S react-datetime@^2
# Note that `react-datetime` depends on `react-onclickoutside@5.9.0`.
pnpm i -S react-datetime@^1
# Note that `react-onclickoutside` is still 5.9.0, but in its `package.json` it depends on `react-onclickoutside@^0.3.4`.
# Delete the `shrinkwrap.yaml` file.
pnpm i -S react-datetime@^1
# Correct dependency is installed.

Aside: Is shrinkwrap used during installation at present, or is it just written to as a record?

@zkochan
Copy link
Member

zkochan commented Mar 3, 2017

Thanks for the steps

shrinkwrap is reused. It is not just for a record.

@vjpr
Copy link
Contributor Author

vjpr commented Mar 3, 2017

So to confirm, when there is a shrinkwrap file present, when I pnpm install it should install the tree defined in the shrinkwrap?

Is it possible to update a single package's dependencies without nuking the shrinkwrap file?

@vjpr
Copy link
Contributor Author

vjpr commented Mar 3, 2017

Just tested - when I modify the version of a dep of a dep in shrinkwrap.yaml, when I pnpm install it will update the dep to the latest, instead of respecting the shrinkwrap.yaml.

@zkochan
Copy link
Member

zkochan commented Mar 3, 2017

oh, right, so currently pnpm always tries to update the top dependencies, when doing pnpm install w/o additional arguments. So for the top deps shrinkwrap is ignored, but the shasum is respected, if no newer version was found.

For the lower deps shrinkwrap is respected though, unless the depth config is specified with a value other then 0

@zkochan zkochan self-assigned this Mar 3, 2017
zkochan added a commit that referenced this issue Mar 3, 2017
BREAKING CHANGE: shrinkwrap format changed

Close #634
zkochan added a commit that referenced this issue Mar 3, 2017
BREAKING CHANGE: shrinkwrap format changed

Close #634
zkochan added a commit that referenced this issue Mar 3, 2017
BREAKING CHANGE: shrinkwrap format changed

Close #634
@zkochan
Copy link
Member

zkochan commented Mar 4, 2017

currently pnpm always tries to update the top dependencies, when doing pnpm install w/o additional arguments. So for the top deps shrinkwrap is ignored, but the shasum is respected, if no newer version was found.

This behavior is confusing, I'll change it so that shrinkwrap will be respected for the top level dependencies as well

@vjpr
Copy link
Contributor Author

vjpr commented Mar 4, 2017

So to clarify the proposed behaviour:

When I pnpm install, the shrinkwrap will be used for all deps.

If I want to update all my deps, I must delete the shrinkwrap file.

If I want to update a single dep and its deps, I can run pnpm i -S foo

The only case that seems to be not possible is: updating deps of deps but not the dep itself. But I don't think this is a common case tbh.


Maybe a FAQ of this functionality would be useful. Something like:

How do I ensure that the same dependency tree is used every time pnpm install is run?

pnpm will install the dep tree in shrinkwrap.yaml by default. The shrinkwrap.yaml will be generated if it does not exist the first time pnpm install is run.

How do I update a single dependency?

You must run pnpm install -S your-dep. This will install the latest version that satisfies the version range specified in the package.json file, and will update all its sub-dependencies.

NOTE: When pnpm install is run, it will install the dependency tree from shrinkwrap.yaml as mentioned above, which may not install the latest version satisfying the version range in the package.json file. Packages must be updated explicitly. This is good practice as it ensures that nothing will break unexpectedly when you install from an empty node_modules folder.

How do I update all my project's dependencies and their dependencies?

You must delete the shrinkwrap.yaml file, and run pnpm install. This will ensure that the latest version possible of all dependencies and their dependencies are installed.

@zkochan Will this work if node_modules is not deleted?

How do I update a single dependency's dependencies, but not the dependency itself?

This is currently not possible.

As a workaround, you can lock your dependency specified in your package.json to an exact version using pnpm i -S my-dep@x.x.x, which will ensure that version x.x.x is installed with its latest dependencies.

@zkochan
Copy link
Member

zkochan commented Mar 4, 2017

Well, you can also update all the top-level deps using pnpm update. And you can set the --depth option to specify the level to which dependencies are updated (0 means the top level). This is the same way it works at with npm

As of npm@2.6.1, the npm update will only inspect top-level packages. Prior versions of npm would also recursively inspect all dependencies. To get the old behavior, use npm --depth Infinity update, but be warned that simultaneous asynchronous update of all packages, including npm itself and packages that npm depends on, often causes problems up to and including the uninstallation of npm itself.

I would personally make it infinity by default..

Of course, I agree that this should be documented.

@zkochan
Copy link
Member

zkochan commented Mar 4, 2017

Fix landed in v0.60.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants