You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
TS1479 Unable to import types from ESM package when moduleResolution is nodenext #54523
When I set moduleResolution: "nodenext" I see this error when I try to import type from a package:
Then I tried to switch to dynamic import() (even in for a type, not a runtime value), and get the same error:
With runtime value, we can typically switch to dynamic import() to get around the problem. But with type imports, this is not getting around the problem.
Here's the error message for searchability:
error message (click to open)
The current file is a CommonJS module whose imports will produce 'require' calls; however, the referenced file is an ECMAScript module and cannot be imported with 'require'. Consider writing a dynamic 'import("wazum")' call instead.
To convert this file to an ECMAScript module, change its file extension to '.mts', or add the field `"type": "module"` to '/Users/trusktr/src/project/package.json'.ts(1479)
Note that the error says
Consider writing a dynamic 'import("wazum")' call instead.
which is what I've done with import('wazum').Add.
Adding typeof has the same issue:
Note, the wazum package is not the one currently at https://npmjs.com/wazum, but the one installed from my current GitHub fork:
Expect there to be some way to import types. import type imports are not regular ES Module imports, so it seems like import type {...} from '...' should just work, however I understand if it should match with the runtimeimport() requirement for CommonJS output for consistency, but that's just not working either.
Plus using dynamic import() syntax for type imports is too cumbersome because some features are missing, f.e. the ability to import generic types:
So even if import() is what I should be doing (currently not working) import type would be better.
Activity
trusktr commentedon Jun 5, 2023
A simple workaround for now is to put a
// @ts-expect-errorcomment over the import:fatcerberus commentedon Jun 5, 2023
Known issue, see #52529.
@ts-ignore/@ts-expect-erroris the only current workaround.bmeck commentedon Jun 5, 2023
Seeing this as well after updating TS, workaround doesn't work as the type is still seen as non-existent.
andrewbranch commentedon Jun 5, 2023
I think you can add the resolution-mode import assertion and ts-ignore the error that tells you not to do that.
This will become an import attribute and not illegal once we land support for import attributes.
typescript-bot commentedon Jun 17, 2023
This issue has been marked as 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.
TheNoim commentedon Aug 26, 2024
This is currently the correct way I guess: