Node version >= 20.0.0 support

[heons]

Core Library

MSAL Node (@azure/msal-node)

Wrapper Library

Not Applicable

Public or Confidential Client?

Public

Description

When I install this package with node version > 20.0.0 it shows this warning.

npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: '@azure/msal-node@1.18.0',
npm WARN EBADENGINE   required: { node: '10 || 12 || 14 || 16 || 18' },
npm WARN EBADENGINE   current: { node: 'v20.4.0', npm: '9.7.2' }
npm WARN EBADENGINE }

Is it just documentation outdated or not being supported yet?
If it is not being supported yet, is there any plan to do so?

Source

External (Customer)

[lalimasharda]

Hey @heons ! We only support node version up to 18 for msal-node v1. We do not plan to support node 20.0.0 in v1 but we will support it for v2 which is in beta right now.

[GottZ]

Hey @heons ! We only support node version up to 18 for msal-node v1. We do not plan to support node 20.0.0 in v1 but we will support it for v2 which is in beta right now.

judging from that, I recommend changing this in npm readme then:

"Will support stable (even-numbered) Maintenance LTS, Active LTS, and Current versions of Node"

[djMax]

You are but a small spec of a MUCH larger ecosystem. It is infuriating for you to put these nonsensical limits in your code. If you want to limit your support, great, do it. But encoding them as overly restrictive engine entries in your package.json is classic Microsoft nonsense.

[tnorling]

While I understand the frustration engines is the idiomatic way to declare what environments a package supports, it's a contract we're committing to. Anything outside of that contract can be overridden with --ignore-engines at your own risk.

msal-node v2 supports node 18 and 20. There are zero breaking changes between v1 and v2 besides dropping support for earlier versions of node. If you need to support 18/20 in addition to older versions you can set your dependency to accept versions 1 || 2

[djMax]

I understand that, but you are Microsoft, and this is a tiny library that almost always exists in a context that is wildly more complex than just this - bundlers, testing infra, containers, hosting platforms... To have to make special decisions for THIS library ignores its position in the pecking order.

[djMax]

The 1 || 2 thing is a good tip though - thanks.