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: handle as-yet unreleased node.js versions #1958

Merged
merged 1 commit into from Mar 19, 2022
Merged

Conversation

davidjgoss
Copy link
Contributor

🤔 What's changed?

Allow any Node.js version equal or greater than 16 as well as the LTS versions 12 and 14

A bit of an oversight when we added enforcement of engines - we don't want to break when a new supported version of Node.js comes out that didn't exist when we released. For example Node.js 18 will be released in April and there's no reason to stop Cucumber users from using it.

🏷️ What kind of change is this?

  • 🐛 Bug fix (non-breaking change which fixes a defect)

📋 Checklist:

  • I agree to respect and uphold the Cucumber Community Code of Conduct
  • I've changed the behaviour of the code
    • I have added/updated tests to cover my changes.
  • My change requires a change to the documentation.
    • I have updated the documentation accordingly.
  • Users should know about my change
    • I have added an entry to the "Unreleased" section of the CHANGELOG, linking to this pull request.

@davidjgoss davidjgoss changed the title chore: handle as yet unrelease node.js versions chore: handle as-yet unreleased node.js versions Mar 19, 2022
@davidjgoss davidjgoss enabled auto-merge (squash) March 19, 2022 12:01
@coveralls
Copy link

Coverage Status

Coverage remained the same at 98.272% when pulling a1388a9 on fix/node-18 into 9e31198 on main.

@davidjgoss davidjgoss merged commit 6feaefb into main Mar 19, 2022
@davidjgoss davidjgoss deleted the fix/node-18 branch March 19, 2022 12:02
@charlierudolph
Copy link
Member

For example Node.js 18 will be released in April and there's no reason to stop Cucumber users from using it.

Yes and no to me. Agree generally we should work with newer versions of node versions and we don't want to block users from trying to use it. I think we should have separate lists for the versions we test against (and thus have validated it works with) vs versions you are capable of running it with.

We could potentially just replace the assertion error with a big warning saying you are running against an unsupported node version.

I saw an example of this in another library recently:

Running a library when a peer dependency doesn't match official support
$ eslint ...
=============

WARNING: You are currently running a version of TypeScript which is not officially supported by @typescript-eslint/typescript-estree.

You may find that it works just fine, or you may not.

SUPPORTED TYPESCRIPT VERSIONS: >=3.3.1 <4.4.0

YOUR TYPESCRIPT VERSION: 4.5.5

Please only submit bug reports when using the officially supported version.

=============

@davidjgoss
Copy link
Contributor Author

davidjgoss commented Mar 21, 2022

I think we should have separate lists for the versions we test against (and thus have validated it works with) vs versions you are capable of running it with.

Makes sense to me. I don't think it's quite apples-to-apples with the typescript-eslint example - if Node.js 18 came out and broke Cucumber then we'd probably have screwed up and would rush out a fix ASAP - but happy to run that change up.

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.

None yet

3 participants