Breaking change for node versions < 20

[sahariko]

• react-error-boundary version: 4.1.0
• node version: 18.12.1
• npm version: 8.19.2

What you did:
Upgraded from version 4.0.3 to 4.1.0

What happened:

error [email protected]: The engine "node" is incompatible with this module. Expected version ">=20". Got "18.12.1"

Problem description:
Version 4.1.0 inadvertently introduced a breaking change with the addition of the engines field to package.json.
Up until this point this package worked fine with versions of node older than 20.

Suggested solution:
Reduce the engines's node version demand.

[bvaughn]

I’m not sure I understand why that setting affects your package. Unless you were trying to build it from source, I don’t understand why the engines setting would impact you?

[onethread]

Getting the same. Yarn is throwing an error for me.

I think engine compatibility with deps has been a thing for a long time now. Npm added it in 2010 npm/npm#6

Fwiw, there is no compiled version in js land, so everything in js land is indeed using direct source.

[sahariko]

I’m not sure I understand why that setting affects your package. Unless you were trying to build it from source, I don’t understand why the engines setting would impact you?

@bvaughn my project is failing during installation, specifically when running yarn install.

[christinna9031]

Can confirm we're getting the exact same error.

[bvaughn]

That's interesting. I wouldn't have expected that since there's no postinstall script or anything 🤔 Hmm. I will roll that change back.

[bvaughn]

Sorry about this, folks. Hopefully [email protected] resolves this issue for everyone?

[Frecherenkel60]

I’m not sure I understand why that setting affects your package. Unless you were trying to build it from source, I don’t understand why the engines setting would impact you?

The engines field imposes restrictions on consumers (docs). On another note, could you also please remove the requirement for pnpm? We're still using yarn (unluckily) and get warnings during install.

 warning [email protected]: The engine "pnpm" appears to be invalid.

[bvaughn]

The "engines" block helps me keep my own PNPM versions straight (so I'm not clobbering my lock files when switching between projects). I should probably find a better way to do this but I'm struggling to have enough time to maintain my open source projects on top of my day job and I'm not sure when I'll get to it.

What you're reporting here is a Yarn v1 bug. Yarn should not be warning about other engines. You can silence the warning for yourselves though by adding the following lines to your .yarnrc:

ignore-engines pnpm

[Frecherenkel60]

The "engines" block helps me keep my own PNPM versions straight (so I'm not clobbering my lock files when switching between projects). I should probably find a better way to do this but I'm struggling to have enough time to maintain my open source projects on top of my day job and I'm not sure when I'll get to it.

What you're reporting here is a Yarn v1 bug. Yarn should not be warning about other engines. You can silence the warning for yourselves though by adding the following lines to your .yarnrc:

ignore-engines pnpm

Wow, I completely misunderstood the concept of the engines field then, sorry for that.

[bvaughn]

No, I'm pretty sure that I misunderstood it (at least the scope of it). I didn't think it would impact anything other than if you were executing package scripts within the repo. As this issue has shown me, it affects installs as well 😭

I'm really sorry that it caused this issue for others, and I'd like to fix it, I just don't have as much free time as I used to 🙇🏼 I appreciate everyone being patient.

[Frecherenkel60]

No, I'm pretty sure that I misunderstood it (at least the scope of it). I didn't think it would impact anything other than if you were executing package scripts within the repo. As this issue has shown me, it affects installs as well 😭

I'm really sorry that it caused this issue for others, and I'd like to fix it, I just don't have as much free time as I used to 🙇🏼 I appreciate everyone being patient.

Well, if it's only about keeping your PNPM versions straight, you could probably enable corepack. You can specify a packageManager field in your package.json where you can pin your versions without affecting your consumers. Here's the according documentation. :)

[bvaughn]

Hmm, Corepack is still experimental isn't it? Either way, until I've done that in all of my projects, it seems like it's too easy to forget to use it and just run pnpm directly (which I think would just "work")

[Frecherenkel60]

Well, yeah. It is still experimental and there are still vivid discussions about the future of it. In my experience it is still worth to use it, because it simplifies the development of multiple projects on the same device without a lot of effort.

Basically you would only need to set the packageManager field in the package.json of every project you're using and run corepack enable once per node version. The rest will be handled by corepack in a predictable fashion as outlined in their docs:

• If the packageManager field is populated in a project and you have the version installed it will directly use it
• If the packageManager field is populated in a project and you don't have the version installed it will ask you to download it
• If the packageManager field is not populated in a project it will use a "known good release"