Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: Support Node LTS and other ranges #2221

Open
maschad opened this issue May 2, 2024 · 4 comments
Open

chore: Support Node LTS and other ranges #2221

maschad opened this issue May 2, 2024 · 4 comments
Labels

Comments

@maschad
Copy link
Member

maschad commented May 2, 2024

The current Node LTS is v20.12.2 with v22 currently available

We currently only support two node versions i.e. ^18.18.2 || ^20.0.0

we should at the very least support the LTS and look to support a range of older and newer versions i.e. 18.18.x -> 22.0.x for example

@maschad maschad added the chore label May 2, 2024
@arboleya
Copy link
Member

arboleya commented May 3, 2024

We already support a range, but yes, let's add ^22 to the mix.

In this case, I don't know if we still need to support ^18.

@maschad
Copy link
Member Author

maschad commented May 3, 2024

We already support a range, but yes, let's add ^22 to the mix.

In this case, I don't know if we still need to support ^18.

My apologies I should've been clearer, but our current package.json only supports either ^18.18.2 || ^20.0.0 , if we try testing on node v19.7.0 for instance (which is in-between 18 & 20) we will get an error.
Screenshot 2024-05-03 at 12 40 22 PM

As opposed to having a broader range support for node engines

such as

{
    "engines": {
        "node": ">=18",
        "pnpm": ">=8"
    }
}

I think it's still worthwhile to support node 18 but I have no data on consumers' environments.

@arboleya
Copy link
Member

arboleya commented May 3, 2024

IIUC, versions 19 and 21 never reached glory and are about to die.

Also, we can't use something like >= 18 because we can't guarantee that new majors won't break the SDK.

This is why using ^N is preferred as it allows for patches and minors, but not majors.

@maschad
Copy link
Member Author

maschad commented May 3, 2024

All good points.

let's add ^22 to the mix.

agree with your original suggestion then

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants