Comments (10)
From an LTS perspective we only support the latest version of an LTS line. This includes the Semver-Minor additions. Part of this is due to security releases, which sometimes themselves have breaking changes.
While project could test against x.0.0 that is generally a bad idea... especially since that release is not guaranteed to be stable (many initial cuts have lots of regressions). A conservative approach could be testing with the initial LTS release... but TBH I think it is very reasonable to have a support contract for the latest Semver-Minor version of an LTS release line.
The Node.js project does a lot of work to ensure that LTS releases do not have regressions... and running on an arbitrary older version of an LTS line not only limits features but is insecure. As mentioned above we could limit ourselves to the features introduced in the initial LTS release, but I don't believe that is necessarily the best limitation. If people need to run in specific Semver-Minor versions of maintenance LTS they are already giving up all sorts of bug fixes and security releases.
Re: >6.0.0, we could in theory bump that as we introduce new features if we know about them... or at the very least pin it to the initial LTS version
v6.10.0 is over 2 years old FWIW
from gaxios.
@MylesBorins That all sounds great but here the comments in #44 show that, just for example, users of Amazon Lambda can either use Node.js v8.10 or v6.10, neither of those are the latest versions in the corresponding branches.
https://docs.aws.amazon.com/lambda/latest/dg/programming-model.html
from gaxios.
Realistically - this library will drop support for node.js 6 the day it goes EOL. It may be worth considering testing Node 8.10, but there's no way we're going back to an older version of 6 at this stage.
from gaxios.
In my mind, this is by design! Technically the node foundation only supports the latest version of any node.js release in the line. Also, node doesn't go LTS until a release after x.0.0, so it doesn't make sense to require something less.
Curious about how @ofrobots and @MylesBorins think about this.
from gaxios.
Quick mention that we communicate through package.json that we support >6.0.0, e.g. https://github.com/googleapis/nodejs-common/blob/791b40273ae07eff93a6ebc0261cc62178614ad2/package.json#L8
from gaxios.
Just wanted to chime in on this ticket since the underlying problem affected me in a bad way βΒ I have a project that runs code on AWS Lambda, still using v6.10 and which uses the googleapis
NPM package for a customer solution. (For perspective, AWS only added support for v8.10 in April 2018 and our node runtime version has not been a primary concern until now.)
The surprise to me was not so much that a major new version of googleapis
stopped working (v37 which switched to gaxios), but that even going back many versions, it still won't work on a fresh npm install because it depends on google-auth-library
which, going back many many versions, depends on gtoken@^2.3.0
.
gtoken v2.3.1 switched to gaxios, and so every version of googleapis
that indirectly has ^2.3.0 as a dependency will also depend on gaxios β even versions released before the end of node 6's LTS.
from gaxios.
@attaboy From experience, since Node 6 is so close to EOL, we'll soon see a bunch of other dependencies stopping supporting it, breaking in some unusual way, and so on. At least that is what happened when Node 4 was EOLed a year ago.
Regardless if this particular package is made to support Node 6 or not, feel free to add my quick and dirty fix for missing URL
constructor from this comment. And think of migrating to Node v8 since AWS supports it.
from gaxios.
@alexander-fenster Understood, and I've already done the first thing and started the migration. π
Again though, it's not unexpected that new versions of a library would stop supporting old versions of Node β but I would urge that in future, such changes be reserved for major version releases rather than patch releases so that they don't have "retroactive" effects given the way the npm tool respects semver.
(That is, this is more a complaint about the decision to switch libraries in a patch release of gtoken, not a complaint about gaxios itselfβ¦ happy to file a ticket on that project with that suggestion, but I suspect the same folks are already here. π)
from gaxios.
Agreed - the fact that it got broken after a set of patch releases looks like a mistake. Good to know that you were able to resolve that in your project.
from gaxios.
For now, I don't think we're planning to make a change here. If we do, it's something we should probably do consistently, and discuss in google-cloud-node.
from gaxios.
Related Issues (20)
- Your .repo-metadata.json file has a problem π€
- Your .repo-metadata.json file has a problem π€
- Ensuring compliance with SNI Extension requirement on remote host HOT 3
- Support proxy option instead of HTTP_PROXY env variable HOT 4
- Get request with one-item array param, will send the value inside instead the the array HOT 1
- Feature request: optional error throwing HOT 2
- π¦ pack and install: "before all" hook: pack and install for "should run the sample" failed HOT 4
- can i please for more docs about comparison with axios HOT 1
- Incorrect GaxiosError message type when request responseType "arrayBuffer" HOT 2
- Uncaught ReferenceError: process is not defined HOT 1
- content-type parsing is performed even if a `text` response type is explicitly requested, causing an unmanageable error HOT 3
- timeout - seconds or milliseconds HOT 1
- feat!: Use Native `cause` in `GaxiosError`
- Using googleapis for direct CSV downloads does not return CSV
- Typo on README.md
- feat: Updated `timeout` Implementation and Documentation HOT 1
- feat: Add `client_secret` to `defaultErrorRedactor` HOT 2
- Warning: a recent release failed HOT 1
- Warning: a recent release failed HOT 1
- Warning: a recent release failed
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gaxios.