You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 11, 2022. It is now read-only.
A flag for npm shrinkwrap to have it output the shrinkwrap JSON to stdout (or alternatively, to a given filepath; either would satisfy my use-case).
What problem is the feature intended to solve?
Being able to output the npm-shrinkwrap.json to a directory other than the CWD.
I want to use a shrinkwrap to lock down my dependency versions when testing on Travis, but I don't want to force my package's dependents to use such exact versions. Thus, I generate a shrinkwrap, but don't keep it in the root of my repository. Since npm shrinkwrap is currently only capable of writing to npm-shrinkwrap.json in the current directory, my "update test npm shrinkwrap" npm script has to include an extra awkward "move npm-shrinkwrap.json" step. If this feature existed, I could get rid of this extra step and just use the shell's output redirection.
Is the absence of this feature blocking you or your team? If so, how?
The lack of this feature means I have to use and depend on an additional tool (currently shx) in my npm scripts just to move the shrinkwrap file to a different directory.
(I can't just use mv since that doesn't work on Windows.)
Is this feature similar to an existing feature in another tool?
Yes, in that unix CLI tools typically either output to stdout by default, or support outputting to stdout by specifying - as filename argument.
Is this a feature you're prepared to implement, with support from the npm CLI team?
Yes.
The text was updated successfully, but these errors were encountered:
othiym23
changed the title
Feature request: Option to output shrinkwrap to stdout instead of npm-shrinkwrap.json
Option to output shrinkwrap to stdout instead of npm-shrinkwrap.json
Jul 28, 2016
We're closing this issue as it has gone thirty days without activity. In our experience if an issue has gone thirty days without any activity then it's unlikely to be addressed. In the case of bug reports, often the underlying issue will be addressed but finding related issues is quite difficult and often incomplete.
If this was a bug report and it is still relevant then we encourage you to open it again as a new issue. If this was a feature request then you should feel free to open it again, or even better open a PR.
For more information about our new issue aging policies and why we've instituted them please see our blog post.
What's the feature?
A flag for
npm shrinkwrap
to have it output the shrinkwrap JSON to stdout (or alternatively, to a given filepath; either would satisfy my use-case).What problem is the feature intended to solve?
Being able to output the
npm-shrinkwrap.json
to a directory other than the CWD.I want to use a shrinkwrap to lock down my dependency versions when testing on Travis, but I don't want to force my package's dependents to use such exact versions. Thus, I generate a shrinkwrap, but don't keep it in the root of my repository. Since
npm shrinkwrap
is currently only capable of writing tonpm-shrinkwrap.json
in the current directory, my "update test npm shrinkwrap" npm script has to include an extra awkward "movenpm-shrinkwrap.json
" step. If this feature existed, I could get rid of this extra step and just use the shell's output redirection.Is the absence of this feature blocking you or your team? If so, how?
The lack of this feature means I have to use and depend on an additional tool (currently shx) in my npm scripts just to move the shrinkwrap file to a different directory.
(I can't just use
mv
since that doesn't work on Windows.)Is this feature similar to an existing feature in another tool?
Yes, in that unix CLI tools typically either output to stdout by default, or support outputting to stdout by specifying
-
as filename argument.Is this a feature you're prepared to implement, with support from the npm CLI team?
Yes.
The text was updated successfully, but these errors were encountered: