Skip to content

force import #596

Closed
Closed
@alidorosty1234

Description

@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!

Activity

NoelAbrahams

NoelAbrahams commented on Sep 4, 2014

@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

NoelAbrahams commented on Sep 4, 2014

@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

danquirk commented on Sep 4, 2014

@danquirk
Member

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

alidorosty1234 commented on Sep 5, 2014

@alidorosty1234
Author

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

vvakame commented on Sep 8, 2014

@vvakame
Contributor

👍
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

Bartvds commented on Sep 8, 2014

@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

NoelAbrahams commented on Sep 8, 2014

@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

mhegazy commented on Sep 8, 2014

@mhegazy
Contributor

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

RyanCavanaugh commented on Sep 8, 2014

@RyanCavanaugh
Member

You can use the amd-dependency flag for this:

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

import x = require('foo');
nikhilk

nikhilk commented on Sep 12, 2014

@nikhilk

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

QueueHammer

QueueHammer commented on Feb 25, 2015

@QueueHammer

@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

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    QuestionAn issue which isn't directly actionable in code

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @nikhilk@vvakame@scottwio@Bartvds@NoelAbrahams

        Issue actions

          force import · Issue #596 · microsoft/TypeScript