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
Can't use typeof for an ambient external module type. #2346
I need to get type information for a CommonJS module that's dynamically (and sometimes conditionally) loaded within the scope of an internal module. Some background on why this is important (and the hoops I go through to work around this restriction today) here: #2327 (comment)
It says that import x = require("y") will not emit anything unless referenced in a value position. Well I assumed that using the keyword require would immediately translate to an actual call to require but apparently I was wrong? So quite unexpectedly:
Seems like import can be used to only import the type (when only use in a type position) but if used as a value would import the module itself. I'm not sure how many TypeScript developers are actually aware of this (perhaps this feature was added, or at least documented, only recently?) as this is quite an ambiguous use of both the keyword import and require.
I would have still found it easier to naturally apply typeof to the ambient type itself. I do realize there might be an technical issue with parsing its identifier (having external module names in quotes perhaps means they could have spaces, start with digits etc. and can't really be used as identifiers). I'm not sure if the syntax chosen is great but it least I've found a way to make it work.
Seems like import can be used to only import the type (when only use in a type position) but if used as a value would import the module itself. I'm not sure how many TypeScript developers are actually aware of this (perhaps this feature was added, or at least documented, only recently?) as this is quite an ambiguous use of both the keyword import and require.
You're definitely not the first to be bitten by this. It is subtle but there are good reasons for it. We've recently been talking about potential alternatives to make this scenario easier/clearer.
Activity
rotemdan commentedon Mar 13, 2015
I found this in the handbook:
http://www.typescriptlang.org/Handbook#modules-optional-module-loading-and-other-advanced-loading-scenarios
It says that
import x = require("y")will not emit anything unless referenced in a value position. Well I assumed that using the keywordrequirewould immediately translate to an actual call torequirebut apparently I was wrong? So quite unexpectedly:ExternalModule.d.ts:
App.ts
emits
Seems like
importcan be used to only import the type (when only use in a type position) but if used as a value would import the module itself. I'm not sure how many TypeScript developers are actually aware of this (perhaps this feature was added, or at least documented, only recently?) as this is quite an ambiguous use of both the keywordimportandrequire.I would have still found it easier to naturally apply
typeofto the ambient type itself. I do realize there might be an technical issue with parsing its identifier (having external module names in quotes perhaps means they could have spaces, start with digits etc. and can't really be used as identifiers). I'm not sure if the syntax chosen is great but it least I've found a way to make it work.danquirk commentedon Mar 14, 2015
Seems like import can be used to only import the type (when only use in a type position) but if used as a value would import the module itself. I'm not sure how many TypeScript developers are actually aware of this (perhaps this feature was added, or at least documented, only recently?) as this is quite an ambiguous use of both the keyword import and require.
You're definitely not the first to be bitten by this. It is subtle but there are good reasons for it. We've recently been talking about potential alternatives to make this scenario easier/clearer.
rotemdan commentedon Mar 14, 2015
Hi, thanks for your reply! It's not every day that I discover a way to do something that I thought was impossible for literally years now.
EDIT: I opened a new issue with a proposal for an alternative syntax: #2357.