search

nodejs / import-in-the-middle

Like `require-in-the-middle`, but for ESM import
https://www.npmjs.com/package/import-in-the-middle
Apache License 2.0
52 stars 20 forks source link

feat: Add package.json engines to pin Node 12+ #119

Open AbhiPrasad opened 1 week ago

AbhiPrasad commented 1 week ago

We should make it clear that this package only supports Node 12+. This also allows us to more easily bump the minimum Node version for future majors.

AbhiPrasad commented 1 week ago

I picked 12.x because this what was in the matrix: https://github.com/nodejs/import-in-the-middle/blob/537cbad6de0f8c186473b2f7d7092c132625e0b2/.github/workflows/ci.yml#L28

Is there another place I should be looking?

For that reason, I wouldn't anticipate wanting to drop support for older versions of Node.js

I think this is very reasonable, and aligns with my personal (and professional) philosophy around this stuff.

Practically speaking though ESM is quite the broken experience in general if you use any version below 18, (import.meta.resolve is only 20.6+ for example 😬), so I'm a little more comfortable being aggressive with version support because I don't assume there are many Node 12, 14, 16 apps with ESM. I would even be fine to sync up completely with OpenTelemetry (they are 14+), and adopt the same node version cadence as them because I feel like they are the primary persona this package needs to support.

What's nice is that we have all the vendors here as well, so we can easily query our systems to figure out what adoption levels are like for various Node versions to understand the ramifications of dropping node support for things.

timfish commented 1 week ago

I picked 12.x because this what was in the matrix

12.x means that the latest CI runs have actually been using the latest v12 release (ie. v12.22.12) rather than 12.0.0, so maybe that's a good minimum?

AbhiPrasad commented 1 week ago

I went ahead and added 12.0.0 to the matrix. I figured this would be better because it doesn't add much to CI time, and have a more liberal engines config is easier to understand for users.

Qard commented 5 days ago

@jsumners-nr That's a nice idea, but that's not reality for many of our customers. There are many companies locked to a Node.js runtime version but able to add and upgrade individual modules within their apps. They expect to have access to our new product features and so upgrade the libraries but still expect it to work with their old runtime versions.

As much as I would like to be able to drop support for EOL versions, it's not really something we can do.