Jest broken on Node 11.11.0

[dmbch]

This is my intent (choose one)

• I want to report a bug
• I want to request a feature or change
• I want to provide or change a feature

The problem

Unfortunately, Jest ist broken on the lates Node version, 11.11.0, see

• fix: handle process[toString] being readonly on newer nodes jestjs/jest#8050
• TypeError on Travis CI jestjs/jest#8070

I only noticed this because the canarist checks in untool that do not use hops’ yarn.lock are failing.

Proposed solution

Upgrade to jest@24.2.0-alpha.0 - since we are hesitant to upgrade to jest@24 in general (#780, #788, #799), we should probably consider alternatives such as updating the engines fields of our packages.

[dmbch]

Could we use a range for the dependencies in question here, i.e. support both jest@23 and jest@24?

[toomuchdesign]

I would also propose considering a more conservative strategy of declaring our engines fields by explicitly mentioning the major versions we want to support.

 "engines": {
    "node": "^8.10 || 9 || 10 || 11",
    "yarn": ">=1.10.1" // Maybe also with yarn?
  },

It might be particularly useful as long as we're keeping pretty strict policies about releasing major versions on our side.

Beside that > means that hops is/will be compatible with the next versions of Node or Yarn, and we don't know that, yet :).

[ZauberNerd]

I asked whether it would be possible to release a fix for Jest 23, but unfortunately it is not (jestjs/jest#8050 (comment)) so we will have to upgrade Jest on our end to v24.

The problem is, that this would be a breaking change, because we expect our users to have jest installed as a dependency in their projects, but we ship the jest-preset-hops which is currently tied to jest 23.
In our preset we have some dependencies to jest packages https://github.com/xing/hops/blob/master/packages/jest-preset/package.json#L30-L37 and since these are dependencies instead of peer dependencies, we can't specify a range on them to support both versions, therefore we have to update the preset to only support v24 and the breakage would then be on the user's side, because they will have to update their local jest dependencies to v24 too.

Unfortunately I don't see another way around this at the moment, so we'll have to discuss whether we want to delay this until the end of the year when we ship Hops 12, or whether we want to release Hops 12 now or if we want break the semver rules and publish it in Hops 11 anyways..

In the long term I would like to see jest completely encapsulated in Hops, so that we provide a command (eg. hops test) which will execute jest, so that our users don't need to install jest or anything else.
That would allow us to update and ship any version of jest that we want to.

@dmbch @toomuchdesign @herschel666 @robin-drexler @jhiode what are your opinions?

[jhiode]

How about a new packages like jest-24-preset-hops? This way users can decide which Jest version they want to use.

[dmbch]

If we were to postpone the Jest upgrade until Hops 12, we would have to limit node versions to <11.11, at least for jest-preset-hops. I personally would consider that an acceptable trade-off, especially considering that it is just a devDependency.

With regards to wrapping Jest altogether..: 😱

[dmbch]

Oh, and we could consider kickstarting a next branch sometime soon. I would prefer that to adding new packages...

[robin-drexler]

In the long term I would like to see jest completely encapsulated in Hops, so that we provide a command (eg. hops test) which will execute jest, so that our users don't need to install jest or anything else.

We're also not wrapping babel in a hops-transpiler package or webpack in a hops-bundler package. What makes jest special in this regard?

Couldn't we, in the future (i.e. hops 12), have jest dependencies be peerDependencies? This would allow to open up the range should new jest versions become available (and still be compatible with what ever we are doing with it :D)

[ZauberNerd]

In the long term I would like to see jest completely encapsulated in Hops, so that we provide a command (eg. hops test) which will execute jest, so that our users don't need to install jest or anything else.

We're also not wrapping babel in a hops-transpiler package or webpack in a hops-bundler package. What makes jest special in this regard?

Yes we do actually - that's what hops build is doing ;)
And other projects, such as CRA are doing the same thing: https://facebook.github.io/create-react-app/docs/getting-started#npm-test-or-yarn-test https://facebook.github.io/create-react-app/docs/running-tests https://github.com/facebook/create-react-app/blob/master/packages/react-scripts/scripts/test.js

[toomuchdesign]

If we can't update to jest v24 only because of the babel-jest dependency declared in jest-preset-hops, releasing a new temporary jest-24-preset-hops package looks a fair trade-off to me in terms of non-breaking releases and providing a working setup on Node 11+.