Last NPM release was 2023-02, but there have been many GitHub commits since then

[cakoose]

As of today, the NPM blake2 package is version 5.0.0, released ~3 years ago. But looking in this GitHub repo, there have been many commits since then. Will a new version be published to NPM?

The concrete issue I ran into is that I'm using the 5.0.0 release from NPM but am getting a build error:

In file included from ../src/blake2.cpp:4:
../../nan/nan.h:2548:8: error: no matching member function for call to 'SetAccessor'
 2548 |   tpl->SetAccessor(
      |   ~~~~~^~~~~~~~~~~
/Users/REDACTED/Library/Caches/node-gyp/22.19.0/include/node/v8-template.h:1049:8: note: candidate fu
 1049 |   void SetAccessor(
      |        ^
 1050 |       Local<String> name, AccessorGetterCallback getter,
      |                           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I think is because this package is not compatible with Node 22. In the GitHub repo, there are commits that look like they might fix my issue. Would be easier to use those fixes if they were published to NPM.

[vrza]

@cakoose Apologies for the belated reply, I just saw this.

there have been many commits since then. Will a new version be published to NPM?

There were no code changes in the project itself after 5.0.0 so I didn't make any new releases -- I consider the package to be stable.

Can you please tell me:

1. does the issue go a way if you install latest master from this repo instead of the packaged version from npm?
2. what version of nan package do you have installed in node_modules?

[cakoose]

There have been updates to the nan dependency since the 5.0.0 release, e.g. 52356e2

I think nan updates matter, since when I install your package via yarn/npm, the native source code is compiled on my machine, and that compilation process depends on nan. That version has to be compatible with both your native source code and the verison of Node I'm using.

With 5.0.0 (I get the compile error above):

$ yarn why nan
└─ blake2@npm:5.0.0
   └─ nan@npm:2.18.0 (via npm:^2.17.0)

With the latest on GitHub (no error):

$ yarn why nan
└─ blake2@https://github.com/vrza/node-blake2.git#commit=52356e2678f19a8838e6153d8662e1746084a5a6
   └─ nan@npm:2.24.0 (via npm:^2.23.0)

[vrza]

Thanks for checking. It does indeed seem that nan 2.18.0 does not compile against Node 22 on MacOS.

However there's still one thing we're missing here. If node-blake2 5.0.0 package (the latest in npm) defines the nan dependency as:

  "dependencies": {
    "nan": "^2.17.0"
  },

then why is yarn on your system installing nan 2.18.0 instead of 2.24.0 (the latest available at this moment)?

I just tried setting the dependency to ^2.17.0, and npm installs nan 2.24.0:

$ npm explain nan
nan@2.24.0
node_modules/nan
  nan@"^2.17.0" from the root project

[cakoose]

I've had my project for a while. When I originally set it up, nan 2.18.0 was probably the latest, so that's what's in the lockfile. Yarn will not automatically upgrade something if there's nothing requiring the upgrade.

It looks like you updated the nan version in your "package.json" to get it compiling on newer Node versions. Why not release that update to NPM?

[vrza]

It looks like you updated the nan version in your "package.json" to get it compiling on newer Node versions.

Oh, that was not the reason. I was simply marking newer versions of dependencies every time I tested the module with a newest version of Node. So I was not aware that an earlier combination of nan and node broke.

Why not release that update to NPM?

I'll definitely release a version 5.0.1 now that I'm aware of the issue with the dependency, to force users' npm/yarn tools to bump the nan version.

But the fact that automated testing did not catch it makes me think how to test better, and catch such regressions. Testing a three-dimensional matrix of every node version vs every OS vs every nan version that some user might have pinned quickly explodes in complexity! And imagine adding a dimension in the testing matrix for every dependency. That seems impractical. Make a library release with every new node release, and/or with every nan release? That also seems impractical.

Since this library is considered completed (I haven't have issues reported in a few years), I'm open to suggestions how to automatically catch regressions between dependencies such as this one.

[vrza]

I added regression testing to Github Actions by including the earliest specified nan version in the test matrix.

Will publish 5.0.1 to npm soon, to make the minimum required nan version explicit.

Just to confirm, you should able to fix your issue even with node-blake2 5.0.0? Simply like this:

$ yarn upgrade nan

[cakoose]

Yes, upgrading nan fixes the problem.

Make a library release with every new node release, and/or with every nan release?

I agree this is annoying, but I think it makes sense?

For example, if a new version of Node makes a backwards-incompatible API change, you have to test that your library (along with all its dependencies) aren't broken by that change.

In this case, (it appears?) Node 22 made a backwards-incompatible change to the native API, and this is the result.

But the fact that automated testing did not catch it makes me think how to test better, and catch such regressions.

One untested thought: Add a CI step to test against the oldest package versions that meet the constraints.

Looks like pnpm has a mode to do that: https://pnpm.io/settings#resolutionmode

[vrza]

One untested thought: Add a CI step to test against the oldest package versions that meet the constraints.

That's what I did earlier today.