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
I was excited when I heard about import type as I've been using dynamic imports on a component to save start up time in vscode for some time, however it's very fragile as I only want to import types and not implementation.
When I try to put the import type guard in place I get the following error though:
What's happening here is I'm wanting to import an export class definition and only reference it as a type by getting its constructor with typeof. However I'm getting an error that it's being used as a value inside a : type definition?
Hm - I suppose the workaround is to use typeof import() types instead, which is pretty reasonable here since all of your imports are distinct anyway so the repetition will be minimal.
I do think that this is working as intended, but I think it begs the question of whether we need import typeof statements. My hunch says "no" because typeof imports probably come up relatively infrequently, and when they do, there's already a way to do this with typeof import("...").Entity.Name. But I'm willing to change my mind if the demand is there.
let Terminal: typeof import("xterm").Terminal would not work as Terminal needs to be top level so it can be references throughout the file and if the import is top level then it will be loaded when the file is loaded (not when the function is triggered)?
This seems to work but I question the usefulness of import type if I can't even use it with my dynamic imports, what other cases would you want to strictly import only types?
Andrew Branch (@andrewbranch) per our Teams discussion it sounds like we landed on allowing typeof T (in type positions) to operate on Ts imported through type-only imports as long as they also have a value meaning
Activity
DanielRosenwasser commentedon Jan 6, 2020
Hm - I suppose the workaround is to use
typeof import()types instead, which is pretty reasonable here since all of your imports are distinct anyway so the repetition will be minimal.I do think that this is working as intended, but I think it begs the question of whether we need
import typeofstatements. My hunch says "no" becausetypeofimports probably come up relatively infrequently, and when they do, there's already a way to do this withtypeof import("...").Entity.Name. But I'm willing to change my mind if the demand is there.Tyriar commentedon Jan 6, 2020
let Terminal: typeof import("xterm").Terminalwould not work asTerminalneeds to be top level so it can be references throughout the file and if theimportis top level then it will be loaded when the file is loaded (not when the function is triggered)?DanielRosenwasser commentedon Jan 6, 2020
Ugh, then you'll really have to write the moral equivalent of a
typeofimport using aliases.Tyriar commentedon Jan 7, 2020
This seems to work but I question the usefulness of import type if I can't even use it with my dynamic imports, what other cases would you want to strictly import only types?
Tyriar commentedon Jan 7, 2020
Is there some easier way to use an interface as a class? It seems ugly to have to spell out the constructor interface?
Tyriar commentedon Jan 7, 2020
See microsoft/vscode#88222 for that approach
RyanCavanaugh commentedon Jan 7, 2020
Andrew Branch (@andrewbranch) per our Teams discussion it sounds like we landed on allowing
typeof T(in type positions) to operate onTs imported through type-only imports as long as they also have a value meaning