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

resolving prepublish-on-install #10074

Closed
othiym23 opened this issue Oct 22, 2015 · 71 comments
Closed

resolving prepublish-on-install #10074

othiym23 opened this issue Oct 22, 2015 · 71 comments

Comments

@othiym23
Copy link
Contributor

@othiym23 othiym23 commented Oct 22, 2015

See also: #3059, #8402, #9722, #9733, probably many others.

Many, many people intensely dislike the fact that a lifecycle event named "prepublish" also gets run when a package is also installed for development, as this precludes the ability to have a set of validation checks that get run before publishing (and also because the name becomes confusingly inaccurate). The reasons for this behavior have been discussed, bikeshedded, and vehemently argued over elsewhere. There is a consensus that the current behavior is undesirable, and the CLI team agrees that this situation needs to be fixed. This is what we intend to do:

  1. Introduce a new prepare lifecycle event, which has the current behavior of the prepublish event – it runs before the package tarball is packed and uploaded to the registry during the publishing process, as well as when you run npm install (with no package name) after cloning a package, to prepare it for use (i.e. by transpiling source).
  2. Introduce a new prepublishOnly lifecycle event, which runs only at prepublish time.
  3. Add a new warning when the prepublish hook is used that the current behavior is deprecated, and will be removed at some point in the future.
  4. In a year or so, make a semver-major bump to npm and make prepublish's behavior match prepublishOnly.
  5. Either then or sometime after that, deprecate prepublishOnly and have just prepare and prepublish.

This should allow everyone to get the behavior they want, and will (eventually) result in a solution that is intuitive and unsurprising to everyone, and allows us to do so in about as gentle a way as possible for something so potentially disruptive.

Thoughts? Things we haven't considered? Parts 1-3 can (and will) be implemented as part of npm@3, probably over the next couple months, so it would be nice to get people's feedback relatively quickly.

@samccone
Copy link

@samccone samccone commented Oct 22, 2015

👍 awesome, this is great

@jasonrhodes
Copy link

@jasonrhodes jasonrhodes commented Oct 22, 2015

\o/ niiiiiice

@robertkowalski
Copy link
Contributor

@robertkowalski robertkowalski commented Oct 22, 2015

+1 that is really good

@fengmk2
Copy link
Contributor

@fengmk2 fengmk2 commented Oct 22, 2015

+1 great!

@ahdinosaur
Copy link

@ahdinosaur ahdinosaur commented Oct 22, 2015

👍 keen

@Fishrock123
Copy link
Contributor

@Fishrock123 Fishrock123 commented Oct 22, 2015

Awesome, thanks!!

@mgol
Copy link

@mgol mgol commented Oct 22, 2015

Sounds great! The new prepare hook will be useful as well.

@dominictarr
Copy link

@dominictarr dominictarr commented Oct 22, 2015

👍 💯 😄

@mathieumg
Copy link

@mathieumg mathieumg commented Oct 22, 2015

🎉

@othiym23 I imagine #8263 will be tackled separately from this?

@JamesMGreene
Copy link

@JamesMGreene JamesMGreene commented Oct 22, 2015

There is a god! 🙏

@SystemParadox
Copy link

@SystemParadox SystemParadox commented Oct 22, 2015

Yes absolutely yes!

@mtscout6
Copy link

@mtscout6 mtscout6 commented Oct 22, 2015

👍 Thanks for tackling this issue!

@AlastairTaft
Copy link

@AlastairTaft AlastairTaft commented Oct 22, 2015

Brilliant 👍

@ljharb
Copy link
Contributor

@ljharb ljharb commented Oct 23, 2015

@othiym23 is there any chance that a tiny 1.x and 2.x patch could be put out, that detects the "prepublishOnly" and "prepare" scripts, and warns that the user should be using npm 3.something to get proper publish behavior? I know modifying 1.x is probably unlikely, but it would be very useful in helping encourage people to update to npm 3, and also ensuring they don't unknowingly miss a critical "before publish" step.

If not, then my only option would be to use in-publish inside "prepublish" for now - but then once "prepublish" does the right thing when your step 4 happens, I'd have to keep in-publish in there forever to ensure that 1.x, 2.x, and too-early-3.x users don't accidentally miss a publish step.

I kind of feel like prepublish should just be decommissioned and never replaced, rather than changing the semantics such that old npm running on an updated module does something surprising.

Steps 1, 2, and 3 seem wonderful to me - it's just steps 4 and 5 I'm concerned about. Instead, if they were a single step 4: In a year or so, make a semver-major bump to npm and remove prepublish, and have just "prepare" and "prepublishOnly". The name will be unfortunate, but I think, less bad than having now-era "prepublish" scripts conflict semantically with future-era "prepublish" scripts.

@othiym23
Copy link
Contributor Author

@othiym23 othiym23 commented Oct 23, 2015

is there any chance that a tiny 1.x

No. The book is closed on npm@1. There is going to be one more release of it that warns people to upgrade to at least npm@2 and that early errors when users try to install scoped packages, strictly so that we can transition to npm@2 in Node 0.10 LTS.

and 2.x

Probably, although we'd be more likely to cherry-pick 1-3 onto the 2.x branch, or add a simple deprecation warning to uses of prepublish that its behavior is changing. That's an LTS discussion, and so will probably involve @zkat and the Node LTS working group.

The reason to wait a year between steps 3 and 4 is twofold - to give developers a chance to migrate to prepare and prepublishOnly, and to give everyone a chance to upgrade to newish versions of npm. There's no reason for people to stay on old versions of npm, even if for whatever reason they can't move off of old versions of Node. We've put a considerable amount of work into keeping npm backwards compatible all the way to Node 0.8. This is especially true for publishers, who need to keep reasonably up to date just so they have an npm that works with the current registry architecture.

I don't think it's especially onerous to include "in order to publish this package, you must be running at least npm@3.4.5" in CONTRIBUTING.md. If you do want to go the extra mile and support old versions of npm, having a dependency on in-publish doesn't seem terrible, either.

Finally, given how the lifecycle works, removing prepublish as an event would require special conditional logic and would violate the symmetry of the model, which would lead to yet more confusion and complaints (and the attendant support load that comes with that), so we're not going to do that.

@ljharb
Copy link
Contributor

@ljharb ljharb commented Oct 23, 2015

Thanks for the detailed answer! If steps 1-3 make it onto 2.x, then I am content to not care about npm 1.

Sadly, CONTRIBUTING.md doesn't help me because documentation is advisory, not enforcement.

I don't understand the last paragraph, but I trust that you know the details far better than I :-)

@othiym23
Copy link
Contributor Author

@othiym23 othiym23 commented Oct 23, 2015

Sadly, CONTRIBUTING.md doesn't help me because documentation is advisory, not enforcement.

To get a little more opinionated for a moment, if you can't get across to your collaborators the basic requirements for working with the code base, there are organizational problems that are far graver than the confusion arising from using inconsistent tool versions.

@ljharb
Copy link
Contributor

@ljharb ljharb commented Oct 23, 2015

That's entirely true - but one could make the same argument about style, and yet using a linter to guarantee consistency is so common a practice that it's often considered bad practice to not do so. People are people, and checks that aren't automated by software will be occasionally skipped.

kentcdodds added a commit to kentcdodds/api-check that referenced this issue Oct 26, 2015
@shellscape
Copy link

@shellscape shellscape commented Oct 27, 2015

👍 to the proposal

@toxicFork
Copy link

@toxicFork toxicFork commented Nov 18, 2015

👍 it's really hurting me in many projects

toxicFork pushed a commit to toxicFork/react-three-renderer that referenced this issue Nov 18, 2015
@peterjuras
Copy link

@peterjuras peterjuras commented Nov 28, 2015

+1

Just saw it by accident, makes no sense to me at all. Now I have to run prepublish work manually to prevent the script from being run when another user installs my modules.

sean-clayton pushed a commit to sean-clayton/react-stackoverflow-profile that referenced this issue Dec 2, 2015
FabienMotte added a commit to fm-ph/quark-state that referenced this issue Oct 18, 2017
FabienMotte added a commit to fm-ph/quark-signal that referenced this issue Oct 18, 2017
FabienMotte added a commit to fm-ph/quark-decorators that referenced this issue Oct 18, 2017
FabienMotte added a commit to fm-ph/quark-package-starter that referenced this issue Oct 18, 2017
thisKai added a commit to thisKai/tilt-effect that referenced this issue Dec 1, 2017
ahmader added a commit to ahmader/node-zoho that referenced this issue Feb 8, 2018
- Update README badges
- Update dependencies and devDependencies
- Rename npm script prepublish to prepare as npm/npm#10074
- Add npm-shrinkwrap.json in bump.
- Update Integration options
- Update Grunt bump script
mroderick added a commit to sinonjs/referee that referenced this issue Mar 3, 2018
* mkdirp dependency missing
* don't run build during prepublish, as that's run by install in node 4

npm/npm#10074
elboman added a commit to elboman/gatsby-remark-embedded-codesandbox that referenced this issue Apr 24, 2018
EnTeQuAk added a commit to mozilla/addons-linter that referenced this issue Jun 25, 2018
This got deprecated in npm 6, see
npm/npm#10074 for much much more details.
@ghost
Copy link

@ghost ghost commented Jul 8, 2018

MIT License

Copyright (c) [year] [fullname]

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

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.