Fix/typescript 4 node module resolution

[nyan-left]

Closes #1760

This PR adds support for TypeScript 4.x and "node" module resolution by fixing import extension handling. Previously, the package only worked with TypeScript 5.x due to .ts extensions in declaration files causing TS2691 errors in earlier versions.

Changes

• Changed imports from .ts to .js, configured in:
  • Jest - moduleNameMapper
  • Docusaurus/Webpack - extensionAlias
• Added tsconfig.load.json for the /load entry point
• Updated just build process:
  • Temporarily rewrites load.ts imports to point to dist/src
  • Generates artifacts and restores source references
• Updated package.json to include load.* files

[vercel]

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

Name	Status	Preview	Comments	Updated (UTC)
yoga-website	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Dec 9, 2024 0:58am

[facebook-github-bot]

Hi @nyan-left!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[NickGerleman]

The .js renaming seems to break resolution in the website build when Webpack tries to find nonexistent .js file.

Module not found: Error: Can't resolve './wrapAssembly.js' in '/vercel/path0/javascript/src'

Also seems to break resolution in test runner.

Let's hold off on doing anything too inorganic to support TypeScript < 5.0, since it's no longer in support.

[nyan-left]

The .js renaming seems to break resolution in the website build when Webpack tries to find nonexistent .js file.

Module not found: Error: Can't resolve './wrapAssembly.js' in '/vercel/path0/javascript/src'

Also seems to break resolution in test runner.

Let's hold off on doing anything too inorganic to support TypeScript < 5.0, since it's no longer in support.

These two are resolved with a bit of config for jest and docusaurus/webpack.

[nyan-left]

@NickGerleman

Regarding linting, given the small nature of the /load.ts, are you happy with ignoring it in eslint?

I'm not too keen on hard coding the tsconfig paths, and afaik a more modular approach like this doesn't currently exist.

[NickGerleman]

Changing the resolvers in each of these is clever 🙂.

It is also the kind of debt that I would like to avoid for TS versions out of support. It means that, any time in the future, if someone adds a .ts import, to some files, but not others, we silently break compatibility, with no indications or tests in the like. I would not like us to change resolution of specific parts of the repo to treat .ts files as .js, for the sake of versions which are out of support.

I'm less concerned with the changes to avoid the need for ESM resolution, since they are still relevant in supported TS versions, and are less likely to break with future code changes.

Re ESLint, we could specialize this specific file in the ESLint config, or we could maybe keep everything in the same project, and just add a step to copy the declaration for this entrypoint?

[nyan-left]

It is also the kind of debt that I would like to avoid for TS versions out of support. It means that, any time in the future, if someone adds a .ts import, to some files, but not others, we silently break compatibility, with no indications or tests in the like.

I think we can solve this via "allowImportingTsExtensions": false in javascript/tsconfig.json. The implication of this would be that we need to tweak generated tests to import from .js or give jest it's own tsconfig. Alternative could also be some eslint extensions setup. Both, lint and tsc happen within the validate-js ci job, so that'll be caught.

Regarding resolvers, it's the reccommended approach by the webpack team. Looks like the only reason it's not the default in webpack already is because webpack doesn't support ts "out of the box". Perhaps one to reporo and make an issue with docusaurus to see their stance.

webpack/webpack#13252 (comment)
webpack/enhanced-resolve#351 (comment)

Jest suggest using ts-jest in TypeScript projects. While I've not personally tested .js extension resolution in it, I'd assume this would work without setup.
https://github.com/jestjs/jest?tab=readme-ov-file#using-typescript

[nyan-left]

Moving the load.d.ts works for me! :)

[nyan-left]

Hi @NickGerleman,

I'm wondering if you have had any further thoughts regarding the allowImportingTsExtensions approach to address your concerns. TypeScript 4 still has millions of weekly downloads 😓 , and we can prevent any silent breakage through compile-time checks.