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.

Sign up for GitHub

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

Jump to bottom

"no exported member" errors when using NodeNext module/moduleResolution in TypeScript #342

Open
bhouston opened this issue Jan 23, 2024 · 4 comments · Fixed by #343
Open

"no exported member" errors when using NodeNext module/moduleResolution in TypeScript #342

bhouston opened this issue Jan 23, 2024 · 4 comments · Fixed by #343
Labels
bug Something isn't working released

Comments

@bhouston
Copy link

  • three version: n/a
  • @types/three version: n/a
  • three-stdlib version: 2.29.4

Problem description:

I ran into this bug and it took a while to figure out. It turns out that this library (as well as threes-stdlib) are not compatible with "NodeNext" module/moduleResolution, e.g. if you tsconfig.json looks like this:

    "module": "NodeNext",
    "moduleResolution": "NodeNext",

And you try to use this library like this:

Code:

import { GLTF, GLTFLoader } from 'three-stdlib'

You will get compile errors via TSC like this:

src/Scene.tsx:17:16 - error TS2305: Module '"three-stdlib"' has no exported member 'GLTFLoader'.

You can work around the bug by switching your tsconfig.json to something like this instead:

    "module": "ESNext",
    "moduleResolution": "Node",

Relevant code:

Included in the above description.

Suggested solution:

I suspect there is some way to fix this? But I do not yet know. One clue is that @react-three/fiber and @react-three.drei work properly with these tsconfig.json settings.
@bhouston bhouston added the bug Something isn't working label Jan 23, 2024
@CodyJasonBennett CodyJasonBennett mentioned this issue Jan 23, 2024
Merged
@rosskevin
Copy link
Contributor

rosskevin commented Jan 19, 2025 •
edited
Loading

Yes, this is bizarre. I just switched to nodenext because https://github.com/sindresorhus/meow required it for a similar reason as mentioned here sindresorhus/meow#248 (comment)

That links to a related babylon issue BabylonJS/Babylon.js#13797

It looks like it could be spec required file extension.

@bhouston how did you end up working around it?

@github-actions GitHub Actions
Copy link

🎉 This issue has been resolved in version 2.35.8 🎉

The release is available on:

Your semantic-release bot 📦🚀

@CodyJasonBennett
Copy link
Member

It looks like it could be spec required file extension.

That is the issue here, in addition to needing the same treatment with .d.cts for CommonJS.

This was referenced Jan 19, 2025
Closed
Merged
@CodyJasonBennett CodyJasonBennett mentioned this issue Jan 19, 2025
Merged
@CodyJasonBennett CodyJasonBennett mentioned this issue Jan 19, 2025
Closed
@CodyJasonBennett
Copy link
Member

Had to revert. We're not given the tools necessary to meet these conditions without directly extending the TypeScript compiler. I do plan to deprecate this package as soon as three accepts any upstream contributions here, and they then require ESM for WebGPU (top-level await). Until then, this library effectively serves as a CJS build for three/addons.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working released
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix: create CTS definition aliases for NodeNext pmndrs/three-stdlib
3 participants
@rosskevin @bhouston @CodyJasonBennett