Can we please have module resolution for AMD?

[blendsdk]

Hi,

I would know what are the possibilities and reservations for having a sort of module resolution
when compiling a project with --module=amd

The context:

• This is about NodeJS and NPM modules
• I am developing a fairly large library that is distributed as an NPM module
• The project ultimately compiles down to a single js file and a single d.ts file.
• The framework consist of many classes, one class per file, and the classes are organized in various namspaces (like we do it in .NET)
• At the consumer side, after installing the lib with npm install --save I use typings install --save --global file:node_modules/path/to/lib.d.ts

The problem and the request

• I use statements like var fs = require('fs'); at the top of some classes. This works at runtime just fine but at develop time, I don't get "intellisense" from VSCode for example, even with adding /// ref and installing dt~node with typings . The compiler sees 'fs' as 'any' because require("fs") is not resolved to an external module.

I understand that is about module resolution and emitting somekind of require statement, but would it be possible to implement such module resolution (just for the sake of intellisense) in the compiler.

Any thoughts?

Thanks.

[yortus]

I use statements like var fs = require('fs'); at the top of some classes.

Have you tried either:

import fs = require('fs'); // old TS import syntax

or

import * as fs from 'fs'; // new ES6 import syntax

Those forms both support compile-time lookup of the types from the imported module, whereas the var x = require(..) form does not.

[kitsonk]

In Dojo 2, we recommend AMD and all of our packages are written in TypeScript. We do not use the default moduleResolution of node, but instead use classic. Generally there are no issues with module resolution, though some of it has not been as easy as it could be, but there are two features coming in TypeScript 2.0 that will solve most of the challenges we have run into (which also solves similar challenges for SystemJS):

• Ability to specify resolution paths so that packages of modules can be re-rooted to match their run time configuration.
• Ability to specify wildcards in the declaration of modules, this allows the modelling of loader plugins better.

The biggest outstanding challenge that is left is with the management of 3rd party typings via typings/typings in that it does not allow the re-basing of the imported modules IDs which means that it makes run-time configuration complex outside of the main module for a package. But that is an issue for typings/typings and not TypeScript.

So, it works today, though with TypeScript 2.0 I cannot think of any other features that could be added to improve module resolution with AMD that TypeScript would need to deliver.

[mhegazy]

a quick addition, In var fs = require('fs'), require is treated as a normal function call, that is defined in your node.d.ts to return any. the compiler does not know that this is a module. use this for your async loading.

for module imports use import fs = require('fs'). this tells the compiler it is a module import to a module called fs. when you build it will be emitted to var fs = require('fs') for nodeJS and define(["require", "exports", 'fs'], function (require, exports, fs) { ... }); for AMD.

For more information about modules, please see http://www.typescriptlang.org/docs/handbook/modules.html

[blendsdk]

@mhegazy, is there anyway to trick the compiler to treat the var fs = require('fs') as import (to get intellisense later in the IDE) without generating the define(.....) and function (require, exports, fs) { ... });. I can do the module resolution and loading myself as I do in [https://github.com/blendsdk/blend-node-library/tree/master/tests/src](Init.js here)

[mhegazy]

Use import fs = require('fs'). emit with --module commonjs. this should generate the same code you want.

[blendsdk]

That does not really work because then every file becomes(or is treated as) a module and I have to go through export/import-ing to get my library accessible from outside. With --module=amd I don't have to do any import export-ing (like in here the ConsoleLogger class is just available and the IDE knows its type), where my "internal" namespaces are also available from outside.

(I know I'm a pain, but I just am trying to find a solution here) (maybe perhaps there is none ATM)

[mhegazy]

i am kinda lost now :) so what is the request/question? it seems you are happy with your current setup using require.

[blendsdk]

Sorry for the confusion. The current setup works at runtime but in this case just for the built-in nodejs modules I don't get intellisense because the compile sees var a = require('b') not as a module import in AMD!

What I don't want to do is:

• use import a = require('a') (undesired code generation)
• use --module=<anything but amd> (undesired module resolution and need to import/export)

As a workaround I can create an interface :

interface NodeFSModule {
    execSync(.....)  ....
    rmdir(.....)
}

// then
var fs:NodeFSModule = require("fs")

// which equals no more fun programming to do for every function in NodeJs FS

Any advice?

[mhegazy]

as i mentioned earlier, the compiler sees require as a function call. you can cast the output to a specific type if you want, so var b: typeof B = reuqire(./b).
ES6 is the new module format, it is being implemented now in browsers, and in node, so I do not think we will be enabling yet another module syntax for cases like these.

[blendsdk]

ok thanks :)

[jwbay]

It might be possible to import the type of fs and use it to annotate a require. if the import is only used in a type position it should get elided (did I use that word right?) during emit.

import fsType = require('fs');

var fs: typeof fsType = require("fs")

fs.readFileSync; //okay? maybe

I think that's as far as you'll be able to get as far as tricking the compiler to mix two module types

[blendsdk]

@jwbay, Thank you. I tried that too, but then the compiler emits the code differently AND I cannot use the simple internal namespace model in other files in the same project.

For demo, I can setup a github repo, to show how easy this way of using modules is. No more import/export, and you can use namespaces just the way you do in .NET :)

@mhegazy , you already have 95% of the code for my request probably :) I have found at least two dozen stackoverflow cases resulting just the same question so there are other people using TS the same way I do. I am willing to dive into implementing it myself but would need a little bit of coaching with regards the codebase and the AST implementation. Would this be acceptable by the TrypeScript team?

[kitsonk]

Ok, I am confused... You are asking for module resolution for AMD, but then are trying to get intellisense for code that you are not importing? I think the title of your question is very confusing.

So what is going to load fs at runtime, if TypeScript isn't going to emit that it is being loaded?

[yortus]

@blendsdk your runtime loader may be AMD, but if your source code works with var fs = require('fs'), then your source code format is effectively CommonJS.

If you set the module=commonjs compiler flag, and write import fs = require('fs'), then you'll get a strongly typed fs, and the emitted code will be var fs = require('fs'), which seems to be what works with your loader.

Perhaps I've missed something about your setup, but what exactly is the problem with telling the compiler to treat your project as CommonJS? I doesn't mean runtime can't still be AMD. We do this exact thing using cajon.