Breaking change in patch version 9.1.0 -> 9.1.1

[monkpit]

If possible it would be great if version 9.1.1 could be unpublished from npm, as it contains a breaking change (node engine) and is not backward-compatible with other 9.x versions.

Our code with a subdependency on version ^9.0.9 recently started to fail due to this issue.

[viper707]

@philsturgeon did you mean to check in: "engines": { "node": ">= 17" },

to version 9.1.1? I see your disclaimer on version 10. Maybe these lines were meant for version 10?

[khevamann]

Also causing issues here!

[danielsalles]

Same

[mikeharder]

The title is slightly incorrect. The breaking change was introduced between 9.1.0 and 9.1.1 (a patch version rather than a minor version).

[jcmosc]

Hey I wrote the PR that broke this. It hadn't hit me that it would autorelease a patch version upon merge since I didn't annotate the relevant commit message as a breaking change.

Suggest pinning to the exact version 9.1.0 if you haven't already, until a 9.1.2 can be released.

Sorry about this!

[mikeharder]

@jamesmoschou: Can you unpublish or deprecate 9.1.1? This might be faster and easier than releasing a 9.1.2, and would fix packages depending on ^9.0.0.

[jcmosc]

@mikeharder I'm not a maintainer, just an external contributor

[rcb4t2]

We're having problems from this too, it's breaking https://github.com/firebase/firebase-tools on our Node 14 CI system

Please roll back as soon as possible, thank you!

@philsturgeon

[monkpit]

Hey I wrote the PR that broke this. It hadn't hit me that it would autorelease a patch version upon merge since I didn't annotate the relevant commit message as a breaking change.

Suggest pinning to the exact version 9.1.0 if you haven't already, until a 9.1.2 can be released.

Sorry about this!

For our use case, we can’t pin the dependency because it’s a dependency of another dependency, and we are consuming it in a package within our own private NPM registry, so lock files are not honored when the package is installed (which is how npm/yarn work).

[emrysal]

@monkpit (and others) you can resolve sub dependencies to a desired version with package.json resolutions.

"resolutions": {
    "@apidevtools/json-schema-ref-parser": "9.1.0",
    ...
},

[khevamann]

@emrysal firebase-tools is installed as a global package. I'm not sure there is a way to add resolutions for that. Especially through CI runners like GitHub actions

[monkpit]

@monkpit (and others) you can resolve sub dependencies to a desired version with package.json resolutions.

"resolutions": {
    "@apidevtools/json-schema-ref-parser": "9.1.0",
    ...
},

This does not appear to work in cases when the consumer of the dependency is a package as opposed to a project with a lockfile (we tried).

[fpmanuel]

@monkpit (and others) you can resolve sub dependencies to a desired version with package.json resolutions.

"resolutions": {
    "@apidevtools/json-schema-ref-parser": "9.1.0",
    ...
},

This does not appear to work in cases when the consumer of the dependency is a package as opposed to a project with a lockfile (we tried).

This works for me, but take a look at your resolutions version, it's 9.1.0 but the previous release is 9.0.9. This should fix your issue:

  "resolutions": {
    "@apidevtools/json-schema-ref-parser": "9.0.9"
  }

PLUS: If you are using a monorepo, add it to the package json in the root of your project.

[monkpit]

@monkpit (and others) you can resolve sub dependencies to a desired version with package.json resolutions.

"resolutions": {
    "@apidevtools/json-schema-ref-parser": "9.1.0",
    ...
},

This does not appear to work in cases when the consumer of the dependency is a package as opposed to a project with a lockfile (we tried).

This works for me, but take a look at your resolutions version, it's 9.1.0 but the previous release is 9.0.9. This should fix your issue:

  "resolutions": {
    "@apidevtools/json-schema-ref-parser": "9.0.9"
  }

PLUS: If you are using a monorepo, add it to the package json in the root of your project.

It does not work (for us - we tried it) when the package.json containing resolutions is within another package that you are publishing. When you consume the published package, resolutions block seems to be ignored.

EDIT: when we tried it, we did use 9.0.9 also.

[jqn]

This is also breaking Gitlab's CI because it doesn't respect the provided solution in package.json

[JEGardner]

Also broke my CI due to globally installing firebase-tools. After resolutions didn't work, my fix is:

yarn global add --ignore-engines firebase-tools @apidevtools/json-schema-ref-parser@9.0.9

Which is ugly but seems to work for me. If there is any way to rollback this change, that would be ideal.

[sesam]

With the release of 10.x there's no longer any simple automated way to get a patch released to solve this, so the options now are to wait for firebase-tools to lock to the previous version and/or ask nicely to get the 9.1.1 (potentially also then 9.1.0) unpublished. And maybe donate some trees :) for speediness.

[julianlam]

In my case, json-schema-ref-parser was a subdependency of @apidevtools/swagger-parser. I am unable to use the latest version as it is not compatible with older Node.js versions. That older version specifies the dependency via semver range ^9.0.6, as do all prior versions along the v10.x line of swagger-parser.

I had to downgrade all the way to swagger-parser@9.0.0 in order to have @apidevtools/json-schema-ref-parser@8.0.0 to be installed.

I would, however, mention that @emrysal's solution worked just fine. However, our GitHub Actions-based test runner seems to ignore the resolutions block in package.json :sweat_smile:

---

Being an OSS maintainer myself, I understand that fixing this is not high on the priority list for @philsturgeon, but I do appreciate that this library is being looked at, so it can get to a level where others can take over. It seems an npm deprecate @apidevtools/json-schema-ref-parser@9.1.1 will resolve this issue nicely. We'll just have to wait patiently :smile:

[Psycarlo]

Installing firebase-tools globally in Github Actions and getting this error

error @apidevtools/json-schema-ref-parser@9.1.1: The engine "node" is incompatible with this module. Expected version ">= 17". Got "16.19.0"

[kariem]

See also this comment related to installing firebase-tools globally

yarn install --ignore-engines

[jcmosc]

Hi all,

v9.1.2 has been released to npm which reverts the breaking changes (which were intended for v10.x but accidentally got released here).

v9.1.2 is effectively the same as v9.1.0 so any systems that were working with that version should be working again after an npm install.

[shassett]

Hi all,

v9.1.2 has been released to npm which reverts the breaking changes (which were intended for v10.x but accidentally got released here).

v9.1.2 is effectively the same as v9.1.0 so any systems that were working with that version should be working again after an npm install.

Thank you so much! -- someone with a child dependency caret-pinned to 9.x.x that couldn't get yarn resolutions to override v9.1.1

[rcb4t2]

Thank you @jamesmoschou !

[CiaranMn]

Using this closed issue as it's where people will end up for 'engine incompatible'.

Are there reasons to impose a minimum version of Node 17 other than tests?

If not, it seems a shame to prevent anyone using the package unless they can use Node 18. Personally I can't in a project due to other dependencies (which is intended for use by others, otherwise I'd consider just --ignore-engines locally).

One alternative would be to have a script that checks Node version when tests are run and bailing if it is insufficient. Then the requirements for development don't propagate to package users.

Appreciate that Node 16 is end of life this year but thought I'd suggest it anyway.

Thanks for a great package!