Switch to a fork of apollo-upload-server to fix missing core-js dependency.#1556
Conversation
…ependency. As reported in #1542, the `apollo-upload-server` package (v5.0.0, which `apollo-server` relies on) is no longer able to provide a `core-js` package because of change that was outside of its control in a Babel release. The problem is resolved in newer versions of `apollo-upload-server`, however, regrettably, the newer versions of that package (notably, v6 and v7) drop support for Node.js 6 — one of two versions of Node.js that are currently under the terms of the Node.js Foundation's Long-Term-Support (LTS) agreements. Since Apollo Server aims to support versions of Node.js which are under LTS (and will drop support for Node.js 6 in April 2019, per Node.js' schedule) the current, immediate solution is to fork the `apollo-upload-server` package as `@apollographql/apollo-upload-server`. With the inclusion of https://github.com/apollographql/apollo-upload-server/pull/1, we are able to keep supporting Node.js 6. Without this change, every new installation of `apollo-server`, which doesn't have a `package-lock.json` preventing transitive dependency updates - specifically, the updates to `@babel/runtime` versions newer than `-beta.56` - is broken.
|
Node 6 is just maintenance lts, is it really necessary to support it? |
|
@ForsakenHarmony Maintenance LTS doesn't mean that we shouldn't aim to support it still. When developers opt to use a LTS version for production environments, they choose LTS versions (of Node.js, Ubuntu, etc.) because they desire — expectedly — long-term support. Maintenance LTS releases still receive updates as they are made available by the teams that support them, and consuming developers should be able to confidently update both the underlying Node.js version, and Ubuntu OS version, and as much of their core infrastructure as possible without needing to concede to a more major upgrade. Apollo is no longer a technology only used by early-adopters! At this very moment, the only other LTS version besides Node.js 6 is Node.js 8. Node.js 10 is slated to become LTS at the end October, if the Node.js Technical Steering Committee decides it's ready. It's currently only designated as Current; it is still subject to non-trivial breaking changes. That's to say, if we dropped support for Node.js 6 right now, we'd only be supporting a single LTS version and it doesn't feel fair to consumers of Apollo Server to only offer one runtime version option. When Node.js 10 stabilizes and becomes LTS, we will consider dropping support for Node.js 6. That said, we will generally try to explore creative opportunities to support all LTS lines. (Related: We were eager to drop support for Node.js 4 almost immediately after it reached EOL, and we're certainly looking forward to moving to engines that support all the latest ECMAScript features natively, as the performance improvements are compelling!) I've written too much more about this in jaydenseric/graphql-upload#109 (comment), but I think you understand our overall commitment to stability and longevity in what we release. |
As reported in #1542, the
apollo-upload-serverpackage (v5.0.0, whichapollo-serverrelies on) is no longer able to provide acore-jspackage because of change that was outside of its control in a Babel release.The problem is resolved in newer versions of
apollo-upload-server, however, regrettably, the newer versions of that package (notably, v6 and v7) drop support for Node.js 6 — one of two versions of Node.js that are currently under the terms of the Node.js Foundation's Long-Term-Support (LTS) agreements.Since Apollo Server aims to support versions of Node.js which are under LTS (and will drop support for Node.js 6 in April 2019, per Node.js' schedule) the current, immediate solution is to fork the
apollo-upload-serverpackage as@apollographql/apollo-upload-server.With the inclusion of https://github.com/apollographql/apollo-upload-server/pull/1, we are able to keep supporting Node.js 6. Without this change, every new installation of
apollo-server, which doesn't have apackage-lock.jsonpreventing transitive dependency updates - specifically, the updates to@babel/runtimeversions newer than-beta.56- is broken.