chore(infra): Upgrade monorepo to use npm@7 and enable engine-strict
#708
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
For those stuck between two lands of npm: If using |
martijnwalraven
force-pushed
the
martijnwalraven/duplicate-fetches-fix-js
branch
from
3423869 to
75a1bb3
Compare
martijnwalraven
force-pushed
the
martijnwalraven/duplicate-fetches-fix-js
branch
from
75a1bb3 to
68a9b55
Compare
Base automatically changed from
martijnwalraven/duplicate-fetches-fix-js
to
main
April 29, 2021 12:27
This also updates the docs repository. The `engines-strict` setting in the `.npmrc` will enforce that the operators of this repository are using the right version. Someone who wishes to circumvent this can pass `--ignore-engines` when running `npm install`, much like someone circumventing a library's own `engines` requirements.
abernix
changed the title
engines-strict
abernix
changed the title
engines-strictengines-strict
|
So I'll have to rebase this PR on Monday after Renovate updates with npm 6 all weekend, but that's easy. Worth noting that the review shouldn't focus on the lockfile contents itself though, because that will change. |
glasser
approved these changes
May 2, 2021
There was a problem hiding this comment.
Seems reasonable enough to me, especially if we land #713 soon so the easy way of "make sure to run with npm v7 locally" is "just use Node 16".
Can you add a motivation for enabling engines-strict somewhere (even just a comment on the PR)? I assume something like "so we can feel the pain of users who have it enabled or use other tools with that default".
martijnwalraven
approved these changes
May 3, 2021
There was a problem hiding this comment.
Looks good to me! (Assuming we land this together with #713, so engines-strict doesn't prevent running on Node >= 15.)
abernix
changed the title
engines-strictengine-strict
glasser
added a commit
to apollographql/apollo-server
that referenced
this pull request
May 3, 2021
Inspired by apollographql/federation#708 This also fixes engines declarations in the individual packages which should have been done in #5137.
glasser
added a commit
to apollographql/apollo-server
that referenced
this pull request
May 3, 2021
Inspired by apollographql/federation#708 as well as the Netlify change in apollographql/federation#713 This also fixes engines declarations in the individual packages which should have been done in #5137.
glasser
added a commit
to apollographql/apollo-server
that referenced
this pull request
May 3, 2021
Inspired by apollographql/federation#708 as well as the Netlify change in apollographql/federation#713 This also fixes engines declarations in the individual packages which should have been done in #5137.
glasser
added a commit
to apollographql/apollo-server
that referenced
this pull request
May 3, 2021
Inspired by apollographql/federation#708 as well as the Netlify change in apollographql/federation#713 This also fixes engines declarations in the individual packages which should have been done in #5137. Also fix a weird problem related to `@apollo/protobufjs`. For some reason, Node 12 and 14 with npm 7 (but not Node 16!) was running into an issue where the fact that `@apollo/protobufjs` doesn't actually depend on a bunch of packages like `espree` that its CLI needs caused the `apollo-pbjs` calls to fail. I think when we forked, protobuf.js was midway through a refactor to make the CLI into a separate package, but we haven't set that up to work in our fork. Adding all those big packages as dependencies of `@apollo/protobufjs` didn't seem great because that would make them non-dev dependencies of apollo-server themselves. Splitting the packages (and making the CLI package a devDep of apollo-reporting-protobuf) is the best long-term solution but for now adding the CLI deps as devDependencies of apollo-reporting-protobuf appears to work?
abernix
added a commit
to apollographql/apollo-tooling
that referenced
this pull request
May 4, 2021
Essentially, the same updates as apollographql/federation#708 The intent of introducing `engine-strict` is to make sure that the users of this monorepo are not led astray into using an unsupported version of Node.js or npm that might cause unexpected side-effects. (Running the wrong version of `npm` is the most motivating reason today!) Users who wish to run this monorepo with a version of Node.js and npm that are not specified in the `engines` range may still do so by running `npm install --no-engine-strict` to acknowledge that there might be unexpected/untested results/outcomes from their actions.
abernix
added a commit
to apollographql/apollo-tooling
that referenced
this pull request
May 4, 2021
Essentially, the same updates as apollographql/federation#708 The intent of introducing `engine-strict` is to make sure that the users of this monorepo are not led astray into using an unsupported version of Node.js or npm that might cause unexpected side-effects. (Running the wrong version of `npm` is the most motivating reason today!) Users who wish to run this monorepo with a version of Node.js and npm that are not specified in the `engines` range may still do so by running `npm install --no-engine-strict` to acknowledge that there might be unexpected/untested results/outcomes from their actions.
abernix
added a commit
to apollographql/apollo-tooling
that referenced
this pull request
May 4, 2021
Essentially, the same updates as apollographql/federation#708 The intent of introducing `engine-strict` is to make sure that the users of this monorepo are not led astray into using an unsupported version of Node.js or npm that might cause unexpected side-effects. (Running the wrong version of `npm` is the most motivating reason today!) Users who wish to run this monorepo with a version of Node.js and npm that are not specified in the `engines` range may still do so by running `npm install --no-engine-strict` to acknowledge that there might be unexpected/untested results/outcomes from their actions.
abernix
added a commit
to apollographql/apollo-tooling
that referenced
this pull request
May 4, 2021
#2302) * chore(deps): Update to npm v7 and enable `engine-strict` Essentially, the same updates as apollographql/federation#708 The intent of introducing `engine-strict` is to make sure that the users of this monorepo are not led astray into using an unsupported version of Node.js or npm that might cause unexpected side-effects. (Running the wrong version of `npm` is the most motivating reason today!) Users who wish to run this monorepo with a version of Node.js and npm that are not specified in the `engines` range may still do so by running `npm install --no-engine-strict` to acknowledge that there might be unexpected/untested results/outcomes from their actions. * Stop testing Node.js 10 Node.js 10 is officially end-of-life as of the end of April 2021. While these packages may and should continue to work for those that are stuck on old versions, those versions are no longer receiving security updates and should be prioritized in terms of getting upgraded to newer versions. * chore: Update to `cimg` images, in preparation for Node.js 16 testing. The newer images are smaller and suggested to be widely cached. In practice, the older images are widely cached because they're still more prevalent but happy to use the newer images, particularly since the older images aren't getting as much in the way of updates anymore (e.g., there are not any Node.js 16 images for it.) Similar in spirit to apollographql/federation@a46cdec * chore: Start testing Node.js 16 * chore: install npm@7 and Node.js 14 on Windows in the easiest way I know how Completely copied from the federation repository. We might want to make an Orb.
3 tasks
trevor-scheer
pushed a commit
to apollographql/apollo-datasource
that referenced
this pull request
Feb 1, 2022
Inspired by apollographql/federation#708 as well as the Netlify change in apollographql/federation#713 This also fixes engines declarations in the individual packages which should have been done in #5137. Also fix a weird problem related to `@apollo/protobufjs`. For some reason, Node 12 and 14 with npm 7 (but not Node 16!) was running into an issue where the fact that `@apollo/protobufjs` doesn't actually depend on a bunch of packages like `espree` that its CLI needs caused the `apollo-pbjs` calls to fail. I think when we forked, protobuf.js was midway through a refactor to make the CLI into a separate package, but we haven't set that up to work in our fork. Adding all those big packages as dependencies of `@apollo/protobufjs` didn't seem great because that would make them non-dev dependencies of apollo-server themselves. Splitting the packages (and making the CLI package a devDep of apollo-reporting-protobuf) is the best long-term solution but for now adding the CLI deps as devDependencies of apollo-reporting-protobuf appears to work?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This upgrades us to use
npm@7at both the root and indocs/and enablesengine-strictvia a root-level.npmrcfile in this repository.The intent of introducing
engine-strictis to make sure that the users of this monorepo are not led astray into using an unsupported version of Node.js or npm that might cause unexpected side-effects. (Running the wrong version ofnpmis the most motivating reason today!)Users who wish to run this monorepo with a version of Node.js and npm that are not specified in the
enginesrange may still do so by runningnpm install --no-engine-strictto acknowledge that there might be unexpected/untested results/outcomes from their actions.