@guardian/ab-react | Use react jsx runtime instead of @emotion/react jsx runtime

[coldlink]

What are you changing?

• Updates the @guardian/ab-react to use the default react/jsx-runtime instead of @emotion/react
• Incorporates changes from remove default jsx handler from tsconfig.base.json #490 to explicitly define the jsx handler in each project

Why?

In identity we noticed an interesting error, where @guardian/ab-react was doing some "interesting" emotion stuff when we imported it causing the bundle to break in the gateway project when attempting to update @guardian/ab-react to a version greater than 3.x.x.

emotion-cache.esm.js:281 Uncaught TypeError: _virtual_stylis_js__WEBPACK_IMPORTED_MODULE_0__.s.exports.middleware is not a function
    at createCache (emotion-cache.esm.js:281:26)
    at ./node_modules/@guardian/ab-react/esm/node_modules/.pnpm/@emotion_react@11.0.0_wk7fohhuxwcjfgq2kdoh4ny7by/node_modules/@emotion/react/dist/emotion-element-14b67335.esm.js (emotion-element-14b67335.esm.js:15:65)
    at __webpack_require__ (bootstrap:19:1)
    at ./node_modules/@guardian/ab-react/esm/node_modules/.pnpm/@emotion_react@11.0.0_wk7fohhuxwcjfgq2kdoh4ny7by/node_modules/@emotion/react/jsx-runtime/dist/emotion-react-jsx-runtime.esm.js (emotion-element-14b67335.esm.js:138:57)
    at __webpack_require__ (bootstrap:19:1)
    at ./node_modules/@guardian/ab-react/esm/libs/@guardian/ab-react/src/context.js (stylis.js:4:35)
    at __webpack_require__ (bootstrap:19:1)
    at ./src/client/static/hydration.tsx (ophan.ts:37:3)
    at __webpack_require__ (bootstrap:19:1)
    at ./src/client/static/index.tsx (hydration.tsx:68:3)

I noticed that at the top of node_modules/@guardian/ab-react/esm/libs/@guardian/ab-react/src/context.js in Gateway was importing jsx from emotion instead:

import { jsx } from '../../../../node_modules/.pnpm/@emotion_react@11.0.0_wk7fohhuxwcjfgq2kdoh4ny7by/node_modules/@emotion/react/jsx-runtime/dist/emotion-react-jsx-runtime.esm.js';
...

I saw that the @guardian/ab-react has a dev dependency on @emotion/react. Looking into why this was added I noticed this commit: 02f8ac1 (#371)

While this allows the build to pass, it also adds a dependency on the emotion jsx runtime to the output file!

For @guardian/ab-react I think should be using the default react jsx runtime.

So after some trial and error, I updated the local tsconfig.json in @guardian/ab-react to do this.

With this make build compiles correctly, and I see in dist/libs/@guardian/ab-react/esm/context.js that the top of the file now uses, which should remove the dependency on @emotion/react!

import { jsx } from 'react/jsx-runtime';

[changeset-bot]

🦋 Changeset detected

Latest commit: 5e1b8fa

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@guardian/ab-react	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[coldlink]

Okay that's interesting, it was building locally fine https://cloud.nx.app/runs/P4FM4RwGNr, but CI is failing 🤔

[coldlink]

Interesting the build works when I build it by itself using

npx nx run @guardian/ab-react:build

https://nx.app/runs/lirOldvecT

[mxdvl]

Good luck with this one–I explored enforcing the order of builds in #373, which made CI pass, but was deemed utltimately a indadequate solution to this problem.

Discussing with @joecowton1 it seemed like as we require Emotion for all consumers of Source, it was acceptable to make it a peer dependency of this project.

For your information, dotcom-rendering no longer loads @guardian/ab-react in favour of using SWR like a provider & current implementation.

[sndrs]

yeah we should 100% not depend on build order to stop typescript breaking!

we should probably not define defaults for JSX handlers at all #490

[coldlink]

yeah we should 100% not depend on build order to stop typescript breaking!

we should probably not define defaults for JSX handlers at all #490

This seems like a better approach to me!

[mxdvl]

Excellent!

I could not crack it in #371 so this is a much welcomed simplification.

[arelra]

Nice detective work!

[joecowton1]

@coldlink should we merge this one?

[coldlink]

@coldlink should we merge this one?

sure merge it when you like! 😄