Consider dropping support for NodeJS 8

[anuraaga]

NodeJS 8 is very old and has been EoL for more than a year. From what I've seen in many projects, changing the minimum supported node version is considered a semver major version change, so to avoid being stuck with that if NodeJS 8 becomes impossible to maintain, it might be worth dropping support for it now.

[anuraaga]

I bring this up mainly because I'm having a really hard time developing in this repo due to NPM performance - I see that yarn was swapped out due to the NodeJS 8 requirement. I noticed yarn workspaces had some issue when tried a while ago, but I think it would be interesting to reinvestigate to see if it can work if it can improve the performance of development, but I guess the minimum NodeJS version is currently a blocker for that.

[dyladan]

I'm willing to consider this but our (internal) metrics still show significant use of version 8

[pauldraper]

FWIW, the oldest supported version by AWS Lambda, Google Cloud Functions, and Azure Functions is Node.js 10 (released Oct 2018).

Considering that Opentelemetry hasn't even yet had a stable release, I'd be surprised by very large intersection of Node.js 8 + Otel.

[dyladan]

I agree. It would be nice if we had some metrics from npmjs.com on which versions of node/npm downloaded the package regularly. Now that the API is out of this repo we could probably more easily move to yarn and drop the node 8 requirement for packages in this repo. We could almost certainly do it for the contrib repo.

[pauldraper]

I just should have looked at end-of-life. Node.js 8 support expired Dec 2019.

In fact, Node.js 10 EOL was actually last month (April 2021).

As a general rule, I suggest supporting versions -- or maybe just LTS versions -- in active support (12, 14, 15, 16).

[dyladan]

For SDK I think that's fair. For API I think we have to go back much further. If we want libraries to build in first-party support for the otel API, we have to impose as few restrictions on them as possible. SDK users are our users, so we can decide on our own restrictions there.

[dyladan]

I can't make this decision alone. I think this requires consensus from at least the other @open-telemetry/javascript-maintainers

[obecny]

The api itself doesn't depend on any package, also doesn't require anything that is not supported on node 8. So I think we should not be really so strict to raise up the api support from node ver. 10 or even 12. From what I know the node 8 works just fine so don't see a reason why we should remove support if we don't have to. Besides we already support it right ?.

With regards to sdk itself I would say that if we encounter any blocker that something simply doesn't work on ver 8 or even 10 we then might consider dropping support, other than that, why should we limit this if we don't have to ?

Is there something that doesn't work either on ver 8 or 10 and we have to make some hacky solutions or sacrifice things that we are not aware of ?

[dyladan]

Yarn doesn't work on node 8. That means we can't run our test infrastructure using yarn for the node 8 tests. The reason to drop support here would be to switch back to yarn because it is a much faster lerna bootstrap that uses fewer resources.

[obecny]

well we can use yarn for other versions and keep 8 as it is. I don't see this as a must to drop support for ver. 8. Some people might be still using it then why we should limit them ?

[pauldraper]

Up to you of course, but my 2c is that Node 8 users are comfortable using an unsupported old version of Node.js; they can use an unsupported old version of @opentelemetry/api. It's not like those are being deleted from npm.

I have no expectation for a library to continue support past the platform itself.

[vmarchaud]

I would prefer to do a GA with the oldest LTS (ie 12) for SDK and node 8 for API (which has a seperate CI etc so seperate tooling seems fine)

[dyladan]

I agree with @vmarchaud

Even if node 8 is supported now, if one of our deps drops support for it then we will need to push a breaking change to update that dep. We can keep it unofficially working but not officially supported.

[Flarna]

Instrumentations usually depend also on @opentelemetry/semantic-conventions and @opentelemetry/instrumentation - which in turn depends on require-in-the-middle (which has some more deps), semver and shimmer.

If we want to be instrumenation friendly these packages should be also considered for the node 8 league.

[anuraaga]

Thanks for the nice discussion! FWIW "We can keep it unofficially working but not officially supported." seems reasonable to me, but also agree with @Flarna's concern that in practical cases there will be a few more libraries needed for instrumentation.

[dyladan]

Sure. If instrumentation is back compatible with 8, then that also opens the possibility for someone who cares enough to implement an 8 compatible sdk if they really want.

[legendecas]

Closing as #3048 has landed.