-
Notifications
You must be signed in to change notification settings - Fork 12.4k
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
isolatedModules refusing to export a type created in the same file #28481
Comments
I'm having a similar issue which is preventing the "re-export" of an interface. Case 1 — Doesn't work: import IUser from './user.ts';
interface IStateProps {
user: IUser;
}
interface IDashboardProps extends IStateProps{};
export { IDashboardProps };
//Error: Cannot re-export a type when the '--isolatedModules' flag is provided. Case 2 — Works: import IUser from './user.ts';
interface IStateProps {
user: IUser;
}
export interface IDashboardProps extends IStateProps{};
//Transpiles successfully Is this an intentional constraint on how interfaces should be exported? Why would exporting as in Case 1 not be allowed? |
Partly related, but maybe it would be useful if TypeScript will support |
OK, I found a really weird workaround, which is basically an extension of @brandontle's - Needs some clarification.... This isolated-modules warning/error will only appear when exporting through import { myVar } from './file1.ts';
export type MyType = typeof myVar; And import { MyType } from './file2.ts';
export type MyTypeAlias = MyType; What I think is that on a What's really weird though, is that you don't need to rename it or give it an alias: import { MyType } from './file2.ts';
export type MyType = MyType; This will work, although it reads as recursive type redefinition, but somehow tsc understands this as just reexporting that type. |
Seeing something similar. In my case I have a couple things being exported from a file, including an interface. When I try to export select parts of the component file in the The component file looks something like this:
In the
...but get...
My workaround was to just use:
|
Any progress here, this behaviour is not expected, is it? |
I'm running into this exact same issue...
|
This is the intended behavior. The intent of the If you compile the OP example with TS, you'll see that If you run the sample example in the Babel repl, you'll see this error because Babel doesn't see any value named
So TypeScript is correctly identifying that this program can't be transpiled by e.g. Babel, which is the point of the flag. |
This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes. |
@RyanCavanaugh Thanks for the explanation, that makes sense. So if it detects any kind of interface in an It's really weird and a little bit unorthodox to not to be able to export it the usual way on the bottom of the page along with the other exports, and as you probably can see this issue has gained plenty of attention in many other repositories. |
@Eksapsy The point of this flag is to be used on code that doesnt get transpiled by TypeScript. TypeScript was first of all invented to add types to JavaScript, Polyfills and that stuff are secondary to that. The TypeScript transpiler was never meant to be doing much more than stripping TypeScript code of the types and adding a few select Polyfills. If you want more freedom you want to use other transpilers, with Babel being the most popular one. Now, stripping the types from TypeScript code turns out to be easier and giving more freedom than queing both Babel and TypeScript transpilers together, thus in a lot of situations (to give one example, create-react-app with TypeScript code) what ends up happening is that your TypeScript code doesn't get transpiled by TypeScript at all, only type-tested, and the stripping of the types and Polyfills (often orienting by the Polyfills the TypeScript compiler adds) is done by Babel. I guess Babel is not willing or at all able to figure out when you export a type and when a value, and thus wouldn't be able to handle that code without freaking out. Anyways, why that doesn't work with Babel isn't really all that important, what's important is that if it can handle it or not is out of the hands of the guys at TypeScript, and thus providing this flag to guard against errors is the best thing they can do. |
@9SMTM6 Yeah that makes sense. I didnt really know that in some situations the typescript code wasn't getting transpiled to regular javascript. Good to know. I guess the flag is pretty important at that situation then and the whole issue is for Javascript to blame as an entity. 😄 We really need typescript to make its own web assembly based language so we can rid off JS 😅 Just kidding, or am I. |
For anyone else who gets here, it looks like this part of @voliva's comment from 11 Jan 2019 is no longer true as of Typescript 3.7:
This is explicitly addressed in the blog post announcing version 3.7 (here). |
It's possible to do this now: export type MyType = import("./file2.ts").MyType; But generics should be duplicated |
Thanks @oriSomething - just tested your suggestion and it works. |
I can see the reasoning behind the flag, I just don't completely agree with it. |
I just ran into this and am still not clear about what happens. If I do type _State = { ... }; then it works as expected. Why does that work but not exporting State directly? |
I am having an issue in version 3.9.3 with this error, I wanted to have a type declared but only export outside of the file the properties I want provided:
It was working in my Stencil JS project but when I copied it over to a React version it suddenly was giving me this error. |
Well i had the same issue but after i have noticed i forgot to put .d.ts extension. |
Having this on NextJs and re-exporting interfaces from index.ts |
Marking interface imports and exports with 'type' prevents them from being exposed after transpilation, thus eliminating ugly warnings of 'name not found'. Refs: webpack/webpack#7378, microsoft/TypeScript#28481
If you came to this issue with the following error
Theres a chance that you didn't notice the last part of the phrase
|
TypeScript Version: 3.2.0-dev.20181110
Code
File 1:
File 2:
Expected behavior:
Code can transpile with --isolatedModules flag
Actual behavior:
Transpile is rejected with error:
Related Issues:
#21194
In that issue, in a comment it's explained that
However, in this other case,
MyType
can only be a type. This also happens when using things likeReturnType
,Pick
, etc.This raises up another question: What happens if in a file we have something like:
In this case,
MyTypeAlias
can also only be a Type - So by that logic we should be able to transpile this file in isolation (by just not emiting any export).The text was updated successfully, but these errors were encountered: