force import

[alidorosty1234]

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!

[NoelAbrahams]

It should be possible to force the emit by writing

var myExternalModule = require("./myExternalModule");

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:

import myExternalModule = require("./myExternalModule"); 
myExternalModule;

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]

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]

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]

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]

👍
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]

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]

It is confusing me.
Why TypeScript compiler eliminate it?

It is an optimisation because sometimes we want to import only the type information from a module:

import foo = require('foo');

function bar(paramOne: foo.ParamOne, paramTwo: foo.ParamTwo){}

[mhegazy]

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]

You can use the amd-dependency flag for this:

/// <amd-dependency path="foo" />

import x = require('foo');

[nikhilk]

Instead of <amd-dependency> which looks like a bit of a hack, it would have been interesting to use <reference name="..."> IMO.

[QueueHammer]

Dan Quirk (@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.