-
Notifications
You must be signed in to change notification settings - Fork 83
Fix package build scripts for git-deps and npm-link symlinks #481
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
Conversation
`prepublishOnly` is an old lifecycle hook created to aid in the transition from prepublish to prepare. Documentation: https://docs.npmjs.com/misc/scripts#prepublish-and-prepare TL;DR: prepare runs before packing and on bare npm-installs. That is, in order for a package to do building/compiling when it is installed as a git-dep (where prepublish _does not run_), one must use `prepare`. This also applies for when a package is symlinked using npm-link. In order to ensure the package is built and can be consumed by the linked dependant, the build must occur via `prepare`. It's also worth noting that `prepare` runs _before_ `prepublish`; so the build step is guaranteed to be complete prior to the prepublish script; for, say, running tests.
The top-level package defined clean and build scripts that were expected to run the (surprise!) clean and build steps of each package. However, most packages named their build step 'tsc' instead of 'build', and virtually none of them had 'clean' as a separate step.
It's frequently necessary to run npm-pack when validating the package tarball is created correctly. This ensures the tarballs are themselves ignored from git. (Keeping user-specific ignores, but those shouldn't be in a repo ignore. User-specific ignores that are OS or IDE specific should be in the user's own ignore file.)
LICENSE, CHANGELOG, README and package.json files are included in tarball automatically.
* master: Leverage rollup's --config* feature for choosing bundles (optimizely#477)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks for cleaning this up 👍 . I had one question about "prebuild"
.
I merged master into this branch, resolved conflicts, then pushed it to https://github.com/optimizely/javascript-sdk/tree/mcarroll/npm-pack.
"tsc": "rm -rf lib && tsc", | ||
"prepublishOnly": "npm run lint && npm test && npm run tsc" | ||
"posttest": "npm run lint", | ||
"prebuild": "npm run clean", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is "prebuild"
a thing? I don't see it documented here. But it does appear to be working as expected when I run locally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pre and post commands with matching names will be run for those as well (e.g. premyscript, myscript, postmyscript)
(That's in the docs linked)
Any pre* script or post* script will run before (or after, respectively) the same-named script.
With the long-standing bug/quirk that a pre* script won't work if the '*' begins with pre. Was meant to disallow preprefoo
running before prefoo
which runs before foo
. However, it has the unfortunate side effect of disallowing preprepare
. Regardless, this is the mechanism that makes preinstall
, postinstall
, prepublish
, postpublish
, work. Those aren't special scripts. They work because any pre/post script will run before/after the corresponding script.
@jasonkarns Apologies for not looking at this earlier. If you are still around and interested to contribute, it would be great if you can give me access to your fork. I just merged master in your branch, resolved conflicts and need write access on your fork to push it. |
@jasonkarns I dont have rights to push to your fork. I pulled your changes, merged master, resolved conflicts, pushed it to a separate branch and created a new pull request #746 . Closing this now. |
…746) ## Background This PR is copied from #481. It was contributed by @jasonkarns a couple of years ago. I just pulled his changes, merged master and resolved conflicts. ## Summary Main change: `prepublishOnly` is the wrong lifecycle script for building/compiling. prepublishOnly does not run during install for git-deps; nor does it run when a package is being symlinked via npm-link. The correct script is `prepare`. This PR: - ensures the build/bundle/compile script is accurately defined as `build` so as to be run properly by the top level `lerna run build` script. - ensures "clean" is run before building - ensures `clean` is defined and exposed such that `lerna run clean` works properly - ensures `build` is invoked during `prepare` lifecycle hook (packing, publishing, git-installing, npm-linking) - preserves `npm test` being run during `prepublishOnly` - adds package tarball pattern to gitignore so npm-pack can be run for inspection - removes unnecessary files from `package.json#files` array (license, changelog, readme, and package.json files are included automatically) - renames CHANGELOG.MD to be cased properly ## Test plan No code changes
Summary
Main change:
prepublishOnly
is the wrong lifecycle script for building/compiling. prepublishOnly does not run during install for git-deps; nor does it run when a package is being symlinked via npm-link. The correct script isprepare
.This PR:
build
so as to be run properly by the top levellerna run build
script.clean
is defined and exposed such thatlerna run clean
works properlybuild
is invoked duringprepare
lifecycle hook (packing, publishing, git-installing, npm-linking)npm test
being run duringprepublishOnly
package.json#files
array (license, changelog, readme, and package.json files are included automatically)Test plan
No code changes
note It's probably also worth cleaning up the lerna publish script. Since building prior to publishing is handled by npm, it's redundant for the lerna publish script to also trigger a build. However, since lerna publish does not support dry-run, I opted not to change this since I can't verify for sure.
But if (during the next
lerna publish
phase) it is observed that packages are being built twice, I would recommend changing:javascript-sdk/package.json
Line 8 in 990245f
"publish": "lerna publish",