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

Comments

Projects
None yet
@aredridel
Contributor

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

This comment has been minimized.

Show comment
Hide comment
@othiym23

othiym23 Sep 29, 2014

Contributor

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 👯

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@thlorenz

thlorenz Sep 29, 2014

Contributor

@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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@timoxley

timoxley Sep 30, 2014

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@othiym23

othiym23 Sep 30, 2014

Contributor

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).

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@timoxley

timoxley Sep 30, 2014

Member

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

Member

timoxley commented Sep 30, 2014

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

@thlorenz

This comment has been minimized.

Show comment
Hide comment
@thlorenz

thlorenz Sep 30, 2014

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@othiym23

othiym23 Oct 4, 2014

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@aredridel

aredridel Oct 6, 2014

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@glenjamin

glenjamin Jan 26, 2015

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@jayphelps

jayphelps 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.

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

This comment has been minimized.

Show comment
Hide comment
@jayphelps

jayphelps 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

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

This comment has been minimized.

Show comment
Hide comment
@glenjamin

glenjamin Mar 21, 2015

Contributor

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

Contributor

glenjamin commented Mar 21, 2015

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

@jayphelps

This comment has been minimized.

Show comment
Hide comment
@jayphelps

jayphelps Mar 21, 2015

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

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

@hemanth

This comment has been minimized.

Show comment
Hide comment
@hemanth

hemanth Jul 7, 2015

tar -tf $(npm pack)

hemanth commented Jul 7, 2015

tar -tf $(npm pack)

@othiym23

This comment has been minimized.

Show comment
Hide comment
@othiym23

othiym23 Aug 4, 2015

Contributor

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

Contributor

othiym23 commented Aug 4, 2015

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

@iarna

This comment has been minimized.

Show comment
Hide comment
@iarna

iarna Aug 4, 2015

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment

@iarna 😓

laughinghan added a commit to laughinghan/npm that referenced this issue Jun 16, 2016

doc: Mention npm-publish(1) mentions npm-pack(1)
This would've been helpful to at least one person other than me:
npm#6351 (comment)

laughinghan added a commit to laughinghan/npm that referenced this issue Jun 16, 2016

doc: npm-publish(1) mentions npm-pack(1)
This would've been helpful to at least one person other than me:
npm#6351 (comment)
@othiym23

This comment has been minimized.

Show comment
Hide comment
@othiym23

othiym23 Sep 15, 2016

Contributor

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!

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@legodude17

legodude17 Sep 23, 2016

Contributor

Can I try taking a crack at this?

Contributor

legodude17 commented Sep 23, 2016

Can I try taking a crack at this?

@brodybits

This comment has been minimized.

Show comment
Hide comment
@brodybits

brodybits 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.

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

This comment has been minimized.

Show comment
Hide comment
@KenanY

KenanY Nov 1, 2016

Member

@brodybits This functionality has not yet been implemented.

Member

KenanY commented Nov 1, 2016

@brodybits This functionality has not yet been implemented.

@npm-robot

This comment has been minimized.

Show comment
Hide comment
@npm-robot

npm-robot 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.

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

This comment has been minimized.

Show comment
Hide comment
@winniehell

winniehell Aug 6, 2017

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

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

@rodoabad

This comment has been minimized.

Show comment
Hide comment
@rodoabad

rodoabad Oct 25, 2017

Voting to get opened!

Voting to get opened!

@glebsts

This comment has been minimized.

Show comment
Hide comment
@glebsts

glebsts Dec 4, 2017

please vote for #19308

glebsts commented Dec 4, 2017

please vote for #19308

@zkat

This comment has been minimized.

Show comment
Hide comment
Member

zkat commented May 10, 2018

#19908 ;)

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