-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Clean up build scripts #12305
Clean up build scripts #12305
Conversation
|
|
✅ Deploy Preview for apollo-client-docs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
commit: |
size-limit report 📦
|
"engines": { | ||
"npm": "^7.20.3 || ^8.0.0 || ^9.0.0 || ^10.0.0" |
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.
The engines
field was kinda weird as we can tell our consumers which runtime Apollo Client works in, but it doesn't make any sense to prescribe which package manager it works in.
We can also never drop anything from that list without a major. Removing it. We might add a node
field here to indicate actual runtime compatibility, but that's not a concern for this PR and I'm not sure if we should.
"changeset-publish": "npm run build && npm run prepdist:changesets && cd dist && changeset publish", | ||
"changeset-check": "changeset status --verbose --since=origin/main", | ||
"pkg-pr-new-publish": "npm run build && cd dist && pkg-pr-new publish --no-template --compact", | ||
"changeset-version": "changeset version && npm i", | ||
"update-size-limits": "size-limit --json | jq '. | map(select(.sizeLimit) | { key: .name, value: .size}) | from_entries' | tee .new-size-limits.json; mv .new-size-limits.json .size-limits.json" | ||
}, | ||
"engines": { | ||
"npm": "^7.20.3 || ^8.0.0 || ^9.0.0 || ^10.0.0" | ||
"devEngines": { |
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.
Instead I'm adding a devEngines
field which allows us to specify which tooling should be used to develop Apollo Client - we don't need to be backwards compatible here but can bump it from time to time.
Starting with node
22.6
and the npm
version that was released alongside with it here, as that's the node version that introduced --experimental-strip-types
.
We could also go for 23.6
to unflag it (here and everywhere else) - I'm open for discussion :)
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.
I'm down for 23.6
. I just ran the build script with that version installed with no issues, so might as well go for it.
"update-version": "node config/version.js update", | ||
"verify-version": "node config/version.js verify", | ||
"invariants": "ts-node-script config/processInvariants.ts", | ||
"sourcemaps": "ts-node-script config/rewriteSourceMaps.ts", | ||
"rollup": "rollup -c ./config/rollup.config.js", | ||
"prepdist": "node ./config/prepareDist.js", | ||
"prepdist:changesets": "ts-node-script config/prepareChangesetsRelease.ts", | ||
"postprocess-dist": "ts-node-script config/postprocessDist.ts", |
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.
Most of these were called by postbuild
, but we never called them manually on the CLI, so I removed them here.
prepdist:changesets
and inline-inherit-doc
were inlined further down in the commands that call them.
const allSteps = Object.assign({}, buildSteps, additionalSteps); | ||
|
||
const runSteps = args.values.step.flatMap((step) => | ||
step === "build" ? Object.keys(buildSteps) : [step] |
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.
Calling this with --step=build
is a shorthand for the normal build steps - that makes it possible to call it with --step=build --step=prepareChangesetsRelease
instead of being forced to use a much longer command.
- if (isTS) { | ||
+ if (isTS && !process.features.typescript) { |
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.
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.
Good stuff! Thanks for modernizing these
The goal of this PR is to move the build scripts to TS,
use
node
with--experimental-strip-types
instead ofts-node
and unify all the helpers we have in
"scripts"
- we are in a jungleof "node run calls more node run".
That should give us a starting point to grok what our current build
actually does and which parts of it we need to modernize.