-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
import type should not have any effect on output code #41562
Comments
Duplicate of #41513. |
@MartinJohns It isn't because #41513 is the general case, i.e. don't always emit This issue is for the specific case where there are no Even if you accept that all JS files with Or to put it another way, with |
I thought #41513 explicitly mentioned "import type" as well. But my impression was still that it's intentional that any use of module-syntax (aka import/export) leads to the file being treated as a module. This impression aligns with the comment by @andrewbranch in the PR that added type-imports: #35200 (comment)
So if it's not a duplicate, it's at least working as intended. |
@MartinJohns In that case this bug would become with the documentation.
I agree, but in 3.8's release the statement on
This needs to be amended in the 4.0 release notes and documentation to something like:
It would also be really helpful to have some documentation, anywhere, on what we should do instead? Is the TS design intent that web workers/service workers/custom elements/etc should not be able to share type definitions with ES module code? I really don't want to have two versions of Finally I disagree entirely with:
If I'm using The assumption that all files that include At the very least I think this needs to be configurable within TS. If you think the most common intent is that Our only options are:
|
There is no remnant of
I agree that fixing the bug should be mentioned in the breaking-changes section of the release notes.
You're having a top-level import, so the file is a module.
The purpose of
Then you're using it for something it was not designed or intended for. Anyway, I'm going to unsubscribe. 🤷 |
Apart from, you know, the
Er, ok, let's look: https://www.typescriptlang.org/docs/handbook/modules.html#importing-types:
Oh, ok then.
There is no top level
I guess, but it's something that did work, now doesn't, and that there is no workaround for other than either opt out of TS or add something that fixes TS output afterwards. I don't get how this is not a problem with TS.
Fair enough, thanks for the help. |
The fix for this is to replace all instances of - import type { InterfaceType } from './MyLibrary';
+ type InterfaceType = import('./MyLibrary').InterfaceType; I still think the side effect of |
import type
declarations should not appear in the JS output and should not have any effect on the JS output.As of 4.0 adding
import type
to a file causesexport {};
to be added to the output. This worked in 3.8This breaks components that use ES modules syntax (because the rest of project also uses it) but will not be loaded as modules. Examples include service workers, web workers, shared workers and custom elements loaded as side effects.
This is a breaking change with no workaround possible in TS. External workarounds are possible.
The general case has already been raised as #41513, this issue is specifically for the subset where the files only contain
import type
declarations and no plainimport
statements.The documentation for
import type
states:This was the case in 3.8, it is not the case with 4.0
TypeScript Version: 4.0.5
Search Terms:
import type
,export {}
Code
Using
import type
in a file so that TS can check types:Note that this file is not a module and will not be loaded as a module.
Expected behavior:
JS output should not include any reference to the
import type
declaration:Actual behavior:
JS output includes
export {};
to force the output to be a module:Related Issues:
export {};
where this exact issue withimport type
was already identified: Consider emittingexport {}
in all ambiguous module output #38696 (comment)exports {}
into code #41513The text was updated successfully, but these errors were encountered: