Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ES Modules and "moduleResolution":"NodeNext" in v9 #1861

Closed
donmccurdy opened this issue Dec 4, 2023 · 8 comments
Closed

ES Modules and "moduleResolution":"NodeNext" in v9 #1861

donmccurdy opened this issue Dec 4, 2023 · 8 comments

Comments

@donmccurdy
Copy link
Collaborator

donmccurdy commented Dec 4, 2023

Context:

In glTF Transform I ran into some conflicts between how TypeScript bundles types, and upcoming changes to Node.js module resolution. I think Luma and Deck will hit the same problems in v9 (tested against the alpha release), for any TS project using a tsconfig.json like these:

{
    "compilerOptions": {
        "module": "nodenext",
        "moduleResolution": "nodenext",
        "target": "esnext",
    }
}
{
    "compilerOptions": {
        "module": "node16",
        "moduleResolution": "node16",
        "target": "node16",
    }
}

The only fix I'm aware of is to make sure our generated *.d.ts files do all file imports with .js extensions. Perhaps it's possible to configure the build tools to do that, but personally I've found it easier to just add "moduleResolution": "nodenext", in my own tsconfig.json, which enforces .js extensions on all imports in source files.

@donmccurdy
Copy link
Collaborator Author

Also -- the fix above should be fully backwards-compatible, so there's no problem with making that change in v9.1 instead of v9.0 if we prefer.

@ibgreen
Copy link
Collaborator

ibgreen commented Dec 4, 2023

In loaders.gl we run a script call add-js-to-imports

#/bin/sh

echo '# Adding .js to import statements in dist folders'
find modules/*/dist -name "*.js" -exec sed -i '' "s/from '\.\(.*\)';/from '.\1.js';/" {} \;
find modules/*/dist -name "*.js" -exec sed -i '' "s/from '\.\(.*\)\.js\.js';/from '.\1';/" {} \;

@donmccurdy
Copy link
Collaborator Author

That looks like a good solution to me, and definitely less churn than changing all source imports. Potentially then, we'd put something like that in each repository? It doesn't seem like that script is running in loaders.gl now, I don't see it called anywhere, and the suffixes are missing from published types –

https://unpkg.com/@loaders.gl/gltf@4.0.4/dist/index.d.ts

@donmccurdy
Copy link
Collaborator Author

It seems this affects node16 module resolution in typescript, and not just nodenext. This section of the TS docs was helpful for me:

https://www.typescriptlang.org/docs/handbook/modules/reference.html#node16-nodenext-1

@ibgreen
Copy link
Collaborator

ibgreen commented Jan 30, 2024

@Pessimistress

There is a need of adding explicit .js extensions to import statements in generated code as required by Node ESM?

Does the new ocular setup have a plugin to do this (I was assuming one of the plugins you used in the last PR did this), or do we need to add back post processing scripts?

@Pessimistress
Copy link
Collaborator

https://github.com/visgl/deck.gl/blob/x/esm/tsconfig.module.json

@ibgreen
Copy link
Collaborator

ibgreen commented Mar 25, 2024

@donmccurdy Can this be closed with the latest ocular changes?

@donmccurdy
Copy link
Collaborator Author

donmccurdy commented Mar 25, 2024

Yes, the change to ocular, post-processing type definitions to include .js extensions like this ...

// modules/foo/dist/index.d.ts
export type { Foo } from "./foo.js";

... does resolve this issue. 👍🏻

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants