json-schema-ref-parser: Breaking change in patch version 9.1.0 -> 9.1.1

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.

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).

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

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 😅

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 😄

@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 (and others) you can resolve sub dependencies to a desired version with package.json resolutions.

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

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.

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).

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!

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

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.

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

@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.

@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.