Refactor researcher app to use ECMAScript modules (ESM)

[barbarah]

This pull request details the transition of the research app and dataset browser from CommonJS to ECMAScript Modules (ESM). The motivation behind this move is to align our projects with modern JavaScript standards, improve module interoperability, and prepare our codebase for future scalability and performance enhancements.

Next.js 13+ supports ESM simply by adding type: module to your package.json and renaming next.config.js → next.config.mjs.

Step 1: Type module in package.json

Node.js allows JavaScript to be interpreted as an ES module via the package.json "type" field with a value of "module". Most config files are in CommonJS, so they need to be updated. If possible, I used .ts for config files. For others, alternative formats were chosen, as detailed below.

• Next.js: Now uses next.config.mjs, as .ts is not supported yet (Next.js Pull Request #57656).
• ESLint: Transitioned to .eslintrc.json from .eslintrc.js based on ESLint's documentation.
• PostCSS: Changed to postcss.config.json from postcss.config.js, in line with Next.js PostCSS configuration guidelines.
• Tailwind: Updated to tailwind.config.ts.
• Jest: Due to an issue with ESM (Jest Issue #11453), moved to .cjs format for jest.setup.js and jest.config.js.

Step 2: Updating the typescript config

For Next.js, the recommended settings are module: esnext and moduleResolution: bundler:

module: esnext instructs TypeScript to output ESM syntax, similar to nodenext, but it's a more general setting that isn't tailored exclusively to Node.js. It's suitable for code running in various environments, including browsers and bundlers (like Webpack, which Next.js uses internally).

moduleResolution: bundler tells TypeScript that module resolution will be handled by a module bundler, which can apply additional transformations or optimizations to the modules beyond what Node.js's native ESM resolution does.

These changes needed some minor updates:

1. src/i18n.ts gave errors; I updated it based on the newest example code of next-intl
2. package iso-639-1-dir showed some typescript errors, I replaced it with the package it was forked from (and now updated) iso-639-1.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
colonial-collections-dataset-browser	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 15, 2024 8:54am
colonial-collections-researcher	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 15, 2024 8:54am

[barbarah]

@sdevalk This is the first part of the ESM conversion. I have only updated the researcher app, but now I know what needs to be done, I can easily change the rest.

I have NOT changed the module setting in typescript to nodenext. This gave a lot of errors and needs a lot more refactoring. I'm not sure if this pull request makes sense without this typescript setting. Changing this will take some time.

[sdevalk]

Nice work! I've added two questions.

[barbarah]

Renaming the config packages did give a problem. Cypress gave a weird error after renaming the package tsconfig to @colonial-collections/ts-config. This disappeared after using a relative path for the typescript extends. I think this has to do with the ts-node Cypress uses; there are multiple ts-node issues with extends. Looking at the issues, I believe ts-node works better with a relative path. I see we already use relative paths for our base config: https://github.com/colonial-heritage/colonial-collections/blob/main/packages/tsconfig/base.json.

[sdevalk]

Nice!