Summary

Changes the JSX runtime/transform from classic to automatic to enable future upgrades to the likes of Turbopack and the Next.js App Router

This is an 'under-the-hood' change with no visible/user-facing benefit, but allows for slightly better developer experience as it removes the need to have the /** @jsx jsx */ pragma defined at the top of components that use Emotion css styles. It also removes the need to explicitly import React and the Emotion jsx function into components.

The Babel config is also removed from the Next.js app. This hands over compliation to Next itself, meaning we leverage its built in SWC compiler to improve build speed slightly, but ultimately removes dev overhead maintaining Babel configuration and its dependencies.

Code Changes

• Switches JSX runtime from classic to automatic in the Express app. The Next.js app does this automatically.
• Sets importSource to @emotion/react in Express Babel and tsconfig to allow Emotion to control JSX behaviour:

  simorgh/babel.config.main.js

  Lines 62 to 65 in 7321aba

  	[
  	'@babel/preset-react',
  	{ runtime: 'automatic', importSource: '@emotion/react' },
  	],

  simorgh/tsconfig.json

  Lines 17 to 18 in 7321aba

  	"jsx": "preserve",
  	"jsxImportSource": "@emotion/react",

• Removes /** @jsx jsx */ pragma requirement for components styled with Emotion css function
• Removes import of jsx from @emotion/react from all components as this is handled by importSource: @emotion/react in the Express app and compiler: { emotion: true } in the Next app
• Removes explicit import of React from all components as this is no longer needed under the new runtime
• Removes babel config from Next.js app, instead deferring to its built-in compiler
• Moves OG, local data serving and status APIs back to Pages Router. Next didn't like the OG API using JSX in the App Router as it thought it tried to import Emotion using its own SWC compiler. Emotion isn't supported in the App Router yet. Moving this back to the Pages Router fixes this problem, so I just moved the other APIs back as well as theres no benefit having a mixed economy
• Uses next/jest to build Jest configs in the Next app. This removes the need to define a transform in each config as Next uses its own compiler to do this: https://nextjs.org/docs/pages/guides/testing/jest#manual-setup
• Flips behaviour of the Babel transform-rename-import plugin, moving it to the Express app instead of being in the Next.js app:

  simorgh/babel.config.main.js

  Lines 8 to 11 in 7321aba

  	[
  	'transform-rename-import',
  	{ original: 'next/dynamic', replacement: '@loadable/component' },
  	],

Developer Checklist

• UX
  • UX Criteria met (visual UX & screenreader UX)
• Accessibility
  • Accessibility Acceptance Criteria met
  • Accessibility swarm completed
  • Component Health updated
  • P1 accessibility bugs resolved
  • P2/P3 accessibility bugs planned (if not resolved)
• Security
  • Security issues addressed
  • Threat Model updated
• Documentation
  • Docs updated (runbook, READMEs)
• Testing
  • Feature tested on relevant environments
• Comms
  • Relevant parties notified of changes

Testing

• Manual Testing required?
  • Local (Ready-For-Test, Local)
  • Test (Ready-For-Test, Test)
  • Preview (Ready-For-Test, Preview)
  • Live (Ready-For-Test, Live)
• Manual Testing complete?
  • Local
  • Test
  • Preview
  • Live

Additional Testing Steps

1. List the steps required to test this PR.

Useful Links

• Coding Standards
• Repository use guidelines
• Add Links to useful resources related to this PR if applicable.