search

desktop / registry-js

A simple and opinionated library for working with the Windows registry
MIT License
154 stars 47 forks source link

LTS policy #145

Closed vweevers closed 5 years ago

vweevers commented 5 years ago

Hi :) I noticed that registry-js@1.5.0 dropped prebuilds for node 8 (dbceb16f9be1d8e7ffbf38bf067bb57a3ae71f63). Node 8 isn't EOL yet, so I'm wondering what your policy is regarding node versions and/or prebuilds, if any?

shiftkey commented 5 years ago

@vweevers that decision was based on my experiences with supporting keytar, and having to support prebuild targets for three platforms, two different runtimes and two different architectures. That project has gotten out of hand because I've just been adding new platforms, and currently looks like this:

I'm 👍 to revisiting this and formalize something for these projects, so here's some current thoughts...

We leverage nan wherever possible to work with with abstractions that work across multiple versions of Node. Beyond that, I'd like to be able to use newer V8 APIs that won't ever be backported to older versions of Node, like we found in https://github.com/desktop/registry-js/pull/144, as well as support context aware modules which are only available in Node 10 or later (https://github.com/electron/electron/issues/18397 has more info).

I fear supporting more platforms means more supporting workarounds.

I also want to note that if you try to build this on a platform when a prebuild is not available, it'll fall back to building from source. That's a bit more graceful than completely dropping support, which was never the intent here.

Looking at the upcoming Node release calendar, later this year I can see the situation where I'd potentially have to support 3 LTS releases (two active, one maintenance), the active version, as well as unstable.

You might not count unstable as a channel worth supporting, but it's been a good canary for me to help identify things before they hit an official release (Electron 5 betas helped me get ready for Node 12, for example).

vweevers commented 5 years ago

Thanks for the elaborate response. I agree that dropping a prebuild isn't necessarily a breaking change, although it can feel like a breaking change for some users (when they didn't need a working node-gyp setup before and now they do).

FWIW in leveldown we've greatly improved our prebuilds situation by switching to N-API and prebuildify. Now any version of Node and Electron use the same prebuild. I.e. we need only one prebuild per platform (osx / win / linux / ..) rather than runtime. This simplification has also allowed us to focus on other platforms, like Android, ARM and Alpine.

shiftkey commented 5 years ago

by switching to N-API

N-API is on my list of things to investigate, and I'm glad this was helpful with improving support

vweevers commented 5 years ago

prebuildify also helped a little bit. Because with prebuildify and its companion node-gyp-build, all prebuilds are included in the npm package. That means there's no download step and users can switch runtimes without rebuilding/reinstalling. For some modules this approach won't be feasible, due to a large number of prebuilds, unless N-API is used ;)

shiftkey commented 5 years ago

Coming back to this after some time off, and I have no issues with keeping this project in sync with upstream LTS support. I've opened #163 to add this back in, and I'll write some docs in the README to clarify this before closing this out.