Suggestion: configurable module directories

[aj0strow]

It would be nice to allow the developer to choose where non-relative modules are loaded from. It should be an ordered array of absolute paths (relative to tsconfig.json).

--resolveFrom [ "./src", "./node_modules", "./bower_components", "./vendor" ]

Scenario

I have an existing legacy es6 + webpack app that is experiencing growing pains. Typescript is a solution for scaling front-end projects.

The issue is typescript can't find my modules because I developed the entire thing with src relative imports, and webpack's resolve.root option. Without proper resolution, modules are not found, and I can't gradually migrate to typescript.

Proposal

Without breaking current module resolution, there should be an additional compiler option to specify where module root directories are located.

Using the example from the docs:

So import { b } from "moduleB" in source file /src/moduleA.ts would result in the following lookups:

Right now the node strategy looks in the following directories, checking multiple file extensions and package json fields.

/root/src/node_modules
/root/node_modules
/node_modules

Instead, the compiler should first check specified module directories in order of preference, and then fallback to node modules going up the file system for backwards compatibility. This is not a build system, it's a way for typescript to find .ts files.

// tsconfig.json

{
    "compilerOptions": {
        "resolveFrom": [
            "./node_modules",
            "./src"
        ]
    }
}

In this case typescript would look in the following places.

/root/node_modules
/root/src
(fallback)

Relative requires would be unaffected. Node requires are unaffected thanks to fallback.

Alignment

Goals

2 - Provide a structuring mechanism for larger pieces of code.

Legacy projects can gradually migrate to using typescript. Existing typescript users can opt-in to have local modules without painful relative requires ../../../../shared/module.

Non-Goals

1- Exactly mimic the design of existing languages. Instead, use the behavior of JavaScript and the intentions of program authors as a guide for what makes the most sense in the language.

Node as existing language. Root relative imports as the intention of program authors.

4 - Provide an end-to-end build pipeline. Instead, make the system extensible so that external tools can use the compiler for more complex build workflows.

Specifying the absolute paths to module resolution folders is simpler than implicit knowledge of node_modules resolution. Build tools, editors, IDEs can all read a static JSON list.

7 - Introduce behaviour that is likely to surprise users. Instead have due consideration for patterns adopted by other commonly-used languages.

Again explicit module resolution contains no surprises. Webpack and NODE_PATH are widely adopted. It's surprising to a number of developers that they can't choose where and how resolution happens.

Related Issues:

• Peek Definition in custom location #11959
• Module resolution strategy for libraries created in Typescript #11809
• Suggestion: NODE_PATH support in module resolution #8760
• Suggestion: Transpile path mappings based module resolution imports to relative paths #6710

Related Questions:

• http://stackoverflow.com/questions/40168500/how-to-require-files-relative-to-root
• http://stackoverflow.com/questions/37606571/absolute-module-path-resolution-in-typescript-files-in-vscode/40177442
• http://stackoverflow.com/questions/34766219/typescript-module-resolution

[mhegazy]

so why not use paths:

// tsconfig.json

{
    "compilerOptions": {
        "paths": {
            "*" : [
                "./node_modules/*",
                "./src/*"
           ]
       }
    }
}

[aj0strow]

@mhegazy I've tried that. It doesn't work, I think because it's not a require.js project.

error TS5060: Option 'paths' cannot be used without specifying '--baseUrl' option.

[aluanhaddad]

paths requires that baseUrl also be set. This should be documented more clearly but it makes sense because these settings come from browser oriented module loaders such as RequireJS and SystemJS.

[aj0strow]

I'm closing in favor of opening a new issue for customizable module loading by writing one function, instead of this madness of trying to support every project layout.