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

Test with all supported node versions #621

Closed
wants to merge 5 commits into from
Closed

Conversation

rotu
Copy link
Contributor

@rotu rotu commented Jun 14, 2024

The package nominally supports node 10 and later. Run CI with all supported node even versions.

@rotu
Copy link
Contributor Author

rotu commented Jun 15, 2024

node 12 is not compatible with minimatch@9.0.4
node 14 fails in node-gyp@10.0.1 nodejs/node-gyp#2947
node 16 fails from the newly introduced execa@9.2.0 which relies on addAbortListener, which was introduced in node 18.

I think it's reasonable to cut support for Node < v18.18.0 and < v20.5.0. @aminya, thoughts?

strategy:
fail-fast: false
matrix:
os:
# - ubuntu-22.04
- ubuntu-20.04
- windows-2022
node_version:
- 18
node_version: [10, 12, 14, 16, 18, 20, 22]
Copy link
Member

@aminya aminya Jun 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather only smoke test the older versions. The scripts and tests are for the developers of this repository who have a controlled environment with access to the latest tools.

So, trying to run these for such old Node versions doesn't really help.

For smoke testing, we can have a setup-node at the end of the pipeline install older node versions and just require zeromq to make sure it loads. The build and testing will be done with the latest Node.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was not expecting CI to pass on these versions - I think we're on reasonably the same page.

Can you please fill in the blanks here?

  • When you develop this package, it is okay to demand Node ___ and pnpm ___. (I think 22/9 is perfectly reasonable)
  • When you consume this package, we expect you to be running Node ___ with package manager ___. (I think 18 / npm, pnpm, yarn berry)
  • When you consume the types of this package, we expect TypeScript ___. (I think >=4.7.4, following the lead of typescript-eslint and DefinitelyTyped.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are good questions. I'd say whatever is defined in CI, is the minimum requirement for the developers, and we aim to support as many as wide Nodejs versions as possible. However, it is not always practical.

So to find the range of Nodejs versions that can consume this project, we can add the above-mentioned smoke tests.

We already have compact tests for TypeScript:

{version: "4.x", minTarget: "es3"},

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say whatever is defined in CI, is the minimum requirement for the developers, and we aim to support as many as wide Nodejs versions as possible. However, it is not always practical.
So to find the range of Nodejs versions that can consume this project, we can add the above-mentioned smoke tests.

I'm not asking what versions can consume this library per CI - as of recently, this library was completely broken in all of its CI. I'm asking what versions should we fix existing tests and set up smoke tests for?

  • I'm asking what versions, if broken, would we regard as a problem?
  • Even that typings compatibility test is maybe not so clear. By setting the version to 4.x I think that means only typescript@4.9.5 is getting checked by CI, but your intention could have been that we support typescript as far back as 4.0. What version of TypeScript do you mean to target and why?

@aminya
Copy link
Member

aminya commented Jun 20, 2024

Closing in favour of #634

@aminya aminya closed this Jun 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants