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

Would love to have a 'dry run' flag for npm publish / pack #6351

Closed
aredridel opened this issue Sep 29, 2014 · 26 comments
Closed

Would love to have a 'dry run' flag for npm publish / pack #6351

aredridel opened this issue Sep 29, 2014 · 26 comments

Comments

@aredridel
Copy link
Contributor

@aredridel aredridel commented Sep 29, 2014

It'd be nice when debugging .npmignore and .gitignore files to have a simple way to show what would be packed -- perhaps an npm pack -n or npm publish --dry-run that simply omits any of the output IO, and sets output to log the files packed.

@othiym23
Copy link
Contributor

@othiym23 othiym23 commented Sep 29, 2014

For now, you can use @thlorenz's irish-pub to see what will be packed by npm pack. You're right, it would be nice to get this integrated into npm itself. Want to take a stab at a PR? :D 👯

@thlorenz
Copy link
Contributor

@thlorenz thlorenz commented Sep 29, 2014

@aredridel you could just use the irish-pub code and put it behind a command in case you do a PR.
Probably wanna use npm lib functions instead of npm as a separate process in that case.

@timoxley
Copy link
Contributor

@timoxley timoxley commented Sep 30, 2014

uh, yet again I've built the same thing as you @thlorenz.

https://github.com/timoxley/pkgfiles

The approach there of grabbing stuff directly from fstream-npm rather than running it through the whole pack/unpack process might be closer to what should happen in npm itself.

@othiym23
Copy link
Contributor

@othiym23 othiym23 commented Sep 30, 2014

You're both pretty. 💏

The prettiest of all will be the one who turns this into a PR. npm publish --dry-run sounds good, but you should wait a day or two until I've slammed npmconf back into the mother ship (that sounds way more violent than I meant).

@timoxley
Copy link
Contributor

@timoxley timoxley commented Sep 30, 2014

also note --dry-run good flag choice, matches equivalent feature in git

@thlorenz
Copy link
Contributor

@thlorenz thlorenz commented Sep 30, 2014

Totally agree with @timoxley that his implementation is closer to what should be used.
Mine has a better name though :-P

@othiym23
Copy link
Contributor

@othiym23 othiym23 commented Oct 4, 2014

This is getting increasingly important as people run into more unexpected issues with publishing. Putting this on the "next minor version" milestone.

@othiym23 othiym23 added this to the 2.2.0 milestone Oct 4, 2014
@aredridel
Copy link
Contributor Author

@aredridel aredridel commented Oct 6, 2014

I'm planning to spend a little work-sponsored time on it this week. Not a ton, but might be able to polish it off.

@othiym23 othiym23 added the next-minor label Oct 7, 2014
@othiym23 othiym23 removed this from the 2.2.0 milestone Oct 7, 2014
@glenjamin
Copy link
Contributor

@glenjamin glenjamin commented Jan 26, 2015

It'd be good if this also explicitly stated which registry URL it is publishing to.

Every time I publish a private module I have a slight hand-in-mouth moment when I wonder if i've got the right config set.

@jayphelps
Copy link

@jayphelps jayphelps commented Mar 21, 2015

Ever since publish -f went away, this missing has caused me to have to literally create throw away package registrations so I can "test" configurations, particularly complex .npmignore scenarios.

@jayphelps
Copy link

@jayphelps jayphelps commented Mar 21, 2015

Tip: you can work around this by trying to publish using an npm user who is not authorized to publish. It will build the tarball and everything, just not publish. You can then untar it and see what would have published. For OSX, it will be localed /Users/your-username/.npm/your-project/X.y.z/package.tgz (you can find the path in your npm-debug.log) See below

@glenjamin
Copy link
Contributor

@glenjamin glenjamin commented Mar 21, 2015

@jayphelps npm pack will build the tarball without publishing - does that not suit your use-case there?

@jayphelps
Copy link

@jayphelps jayphelps commented Mar 21, 2015

@glenjamin yep.....if only I had RTFM....
DOH

@hemanth
Copy link

@hemanth hemanth commented Jul 7, 2015

tar -tf $(npm pack)

@othiym23
Copy link
Contributor

@othiym23 othiym23 commented Aug 4, 2015

@iarna did this for npm@3! She'll be by anon to explain what its deal is.

@iarna
Copy link
Contributor

@iarna iarna commented Aug 4, 2015

Aaaactually, no, I added --dry-run for stuff that effects node_modules and your package.json but these are actually untouched.

@TimFerrell
Copy link

@TimFerrell TimFerrell commented Aug 6, 2015

@iarna 😓

laughinghan added a commit to laughinghan/npm that referenced this issue Jun 16, 2016
This would've been helpful to at least one person other than me:
npm#6351 (comment)
@othiym23
Copy link
Contributor

@othiym23 othiym23 commented Sep 15, 2016

The CLI team still intends to see this functionality added as npm publish --dry-run (and / or npm pack --dry-run), probably using a listener to fstream-npm plus lib/utils/tar.js as described by @timoxley. It would indeed be nice to also include metadata related to the publish, such as the packed package size, the registry to which it would be published, and the user who would be doing the publishing (for optimal offline use, it probably shouldn't actually do any permissions checks against the registry, or at least should downgrade gracefully if the registry isn't available). This seems like something that would be an excellent and reasonably self-contained feature for a contributor not on the CLI team to do, so I've labeled the issue accordingly. Thanks to all for their contributions and patience thus far!

@legodude17
Copy link
Contributor

@legodude17 legodude17 commented Sep 23, 2016

Can I try taking a crack at this?

@brodybits
Copy link

@brodybits brodybits commented Nov 1, 2016

I think there is a bug: I did npm publish --dry-run thinking it would either do a dry run or fail with an error, but it went ahead and published my work! I am using node 6.9.1 with nvm on my macOS system and npm --version returns 3.10.8.

@KenanY
Copy link
Collaborator

@KenanY KenanY commented Nov 1, 2016

@brodybits This functionality has not yet been implemented.

@npm-robot
Copy link

@npm-robot npm-robot commented Jun 19, 2017

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.

@npm-robot npm-robot closed this Jun 19, 2017
@winniehell
Copy link

@winniehell winniehell commented Aug 6, 2017

@othiym23 This was closed automatically—any chance to get it reopened?

@rodoabad
Copy link

@rodoabad rodoabad commented Oct 25, 2017

Voting to get opened!

@glebsts
Copy link

@glebsts glebsts commented Dec 4, 2017

please vote for #19308

@zkat
Copy link
Contributor

@zkat zkat commented May 10, 2018

#19908 ;)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.