Closed
Description
I have many scenarios where I would do this:
import myExternalModule = require("./myExternalModule");
// not using myExternalModule here
I dont use myExternalModule
in my code but still I want it to be included using requirejs. I just need it to be there.
If there could be a forceimport
keyword that would be very cool!
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
NoelAbrahams commentedon Sep 4, 2014
It should be possible to force the emit by writing
but this won't complain if "./myExternalModule" is an incorrect path.
The correct approach is to introduce a dummy reference that has no side-effects:
Although this is a hack, it's very unlikely that new syntax will be introduced for this rather narrow use-case. See the design goals.
NoelAbrahams commentedon Sep 4, 2014
If TypeScript would verify the path in
var myExternalModule = require("./myExternalModule");
then that would permit users to force the emit _and_ get compile-time verification, without having to resort to the hack.danquirk commentedon Sep 4, 2014
The
var
approach doesn't import the types from the module though.Additionally you could use the amd-dependency attribute if you must.
For what purpose are you importing things that aren't used?
alidorosty1234 commentedon Sep 5, 2014
For instance in an angular app I have some directives in other files. I need to import those directives or else my html markup won't work. I don't use them in JavaScript though.
Usually in angular, most modules are decoupled and don't have dependencies on each other, but need to be imported for the whole app to work.
vvakame commentedon Sep 8, 2014
👍
It is confusing me.
Why TypeScript compiler eliminate it?
external module is not non-instantiated module.
require has a side effect.
import clause seems to be compatible with the require of AMD and CommonJS. but it is not.
Bartvds commentedon Sep 8, 2014
This issue is also annoying when require()-ing modules that don't really export anything but instead shim functionality on global objects, like
es5-shim
,es6-shim
and many others.NoelAbrahams commentedon Sep 8, 2014
It is an optimisation because sometimes we want to import only the type information from a module:
mhegazy commentedon Sep 8, 2014
it is not just an optimization. If you are using an imported module for types only (i.e. not used in any value position), we can not emit the require logic for it, as the module can be an ambient type-only module that does not exist at runtime. Emitting a module import would mean a runtime error trying to load a non-existing module.
RyanCavanaugh commentedon Sep 8, 2014
You can use the
amd-dependency
flag for this:nikhilk commentedon Sep 12, 2014
Instead of
<amd-dependency>
which looks like a bit of a hack, it would have been interesting to use<reference name="...">
IMO.QueueHammer commentedon Feb 25, 2015
@danquirk It's an arbitrary and dangerous thing to have the TypeScript engine take on the responsibility of optimizing the import statements. There are many patterns that TypeScript does not yet capture from JavaScript. One example is how it does not address that
this
could have a type #229 .Import is used to load dependencies before the current code is loaded and may not be referenced directly. Angular dependencies are one example, while jQuery plugins are another. Any library that extends a base object and is not referenced directly are affected by "feature". By deciding to arbitrarly not included an import based on local static analysis you are imposing a C style compiler pattern over the explicit intention of the developer who wrote the import statement. The expectation of writing import is that it will be included as a dependency and available to the local scope of the module. Any other action is a side effect to the natural expectation of choosing to write
import
inside a module.It is very possible that in this case the TypeScript compiler could do less, and accomplish more.
24 remaining items