3

I'm currently developing my package with Node v12.14.0 on my local machine but a PR I received from Dependabot made me think about how that influences the compatibility of my library.

  • If I develop my library using v12 features it shouldn't be able to work if run in other versions that have conflicting breaking changes, right?
  • I never bothered specifying an engine restriction in my package.json, is that something I should do? Or is it something that I shouldn't worry about?
  • If there is more than one active LTS version, which one should I use?

I'm just looking to know if there's any "standard"/recommended way to handle this, or if I should just decide which works best for me and not worry about that.

Federico Grandi
  • 6,785
  • 5
  • 30
  • 50
  • It depends. Is the source code what actually gets shipped, or do you have some kind of transpiration (Babel, TypeScript)? Do you *want* or *claim* to support earlier versions of Node? FWIW, in the things I publish to NPM, I try to test against multiple versions of Node (currently 10, 12, 14 - see e.g. https://github.com/textbook/fauxauth#compatibility). – jonrsharpe May 13 '20 at 07:01
  • @jonrsharpe In this specific case I'm shipping the source code, but I have other projects in TS where I ship the compiled version. At the moment I'm not claiming to support anything because I hadn't thought about this before today, I was just wondering if somebody had problems with my package because of this. Testing with multiple versions may not be a bad idea, since that would tell for sure. – Federico Grandi May 13 '20 at 07:10
  • 1
    In that case, shipping the source and only testing in one version, use the *oldest* version you want to support (I'd suggest 10, per https://nodejs.org/en/about/releases/). Otherwise it's less relevant which you happen to be using. – jonrsharpe May 13 '20 at 07:13

2 Answers2

1

There is no "standard" way to handle this. You can put the node version in package.json to define the minimal engine version. 

{ "engines" : { "node" : ">=0.12" } }

If you want to make it available for most of the developers, use the active LTS version. Dubnium (v10) is still supported, so you can define it as a minimum requirement to make it available virtually to everyone.

Alex
  • 4,621
  • 1
  • 20
  • 30
0

As a package developer, you should use the "Current" version.

For everyone else, us the developers, we should use "LTS" long-term support version.

Tamal Anwar Chowdhury
  • 392
  • 3
  • 8