Add support for path mapping to tsconfig.json.

[mko]

Recently (about a week ago), TypeScript added support for a new moduleResolution type called Path Mapping, which allows the user to specify a baseUrl object and paths object for mapping module names to their actual paths, allowing users to not be tied to only using node (i.e. NPM) as an alternative module resolution mode. This opens up the ability for devs to use alternative package managers (like JSPM) and using simplified module import statements for local modules as well.

Path mapping is enabled by setting up your tsconfig.json like so:

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "angular2/*": ["../path/to/angular2/*"],
      "local/*": ["../path/to/local/modules/*"]
    }
  }
}

and using the imports in TypeScript files like so:

import { bootstrap } from 'angular2/bootstrap';
import { module } from 'local/module';

This provides a fix for working with client-side modules installed via JSPM. You can see the details of the implementation in the PR 5728 on the TypeScript project: https://github.com/Microsoft/TypeScript/pull/5728/files

The TypeScript nightly has the fix in place, though the fix isn't in the stable version on NPM, so you have to install TypeScript by npm install -g typescript@next instead of just typescript to reproduce this issue.

Before Path Mapping, I saw numerous errors related to the JSPM module name mappings:

After Path Mapping, those errors disappear and now I see the error about baseUrl being an invalid value:

Clearly, this is a "bleeding edge" issue only, but I know that many other devs using both Angular2 and JSPM are running into this issue. A fix would make the experience of developing Angular2 with JSPM in Atom much more pleasant.

[basarat]

btw nice user handle 👍 @mko 🌹

[laurelnaiad]

@mko , thank you for pushing this along. Are you saying that you changed your tsconfig, wrote some mappings and it "just worked" in atom-typescript (except for the complaint about the tsconfig schema)?

If so, that's great! This feature isn't only useful for angular2 apps, though they are, of course, a significant contingent among the stakeholders.

[mko]

@laurelnaiad I believe so, yes. I updated my local TypeScript to the nightly build which has the updated Path Mapping module resolution, and I updated my TSConfig to match the Path Mapping options. After doing so, the initial 6 module errors were resolved immediately, but the syntax error showed up in the TSConfig. I'm not sure if clearing the syntax error in the TSConfig will uncover more issues, but it seems to be the only thing preventing the new module resolution approach from working.

[laurelnaiad]

An addition to the array in

atom-typescript/lib/main/tsconfig/tsconfig.ts

Line 90 in f50fe08

moduleResolution: { type: types.string, validValues: ['classic', 'node'] },

might take care of that, by the way.

(edit: and now I note that you'd have to define paths as well there)

[mko]

I went through the painful process of figuring out more details on this, and it looks like the moduleResolution value of baseUrl is no longer how to instantiate the paths mapping system. It's now done entirely by including a baseUrl value and paths object. The moduleResolution value doesn't seem to make a difference.

[laurelnaiad]

The moduleResolution value doesn't seem to make a difference.

That's good to hear. That was troubling to me. I'd like to be able to use path mapping in in commonjs-targeted and es6-targeted projects.

[Aaike]

+1

[mpseidel]

@mko have you solved the problem with
Unknown Option: baseUrl
Unknown Option: paths
?

[krisdages]

To get completions in the very short term, I've been symlinking the mapped paths into node_modules and setting the moduleResolution to node. This has been a godsend for anchoring the local imports in src/**/module.ts to "lib", "verbose-package-name", or whatever convenient mapping(s) are configured with SystemJS/JSPM.

/* src/contrived-example/form-xyz/vm.ts */

//import FormVM from '../../common/form-vm'; 
import FormVM from 'lib/common/form-vm';

To do the actual transpilation with path mapping support, I'm using gulp-typescript, an instance of the latest tsc, and a separate hash of compilerOptions instead of the atom plugin. Besides the convenient integration with the existing pipeline while migrating from a plain ES6 platform, the allowJs option has also come in handy.

/* jspm.config.js */

//Just one of many ways to route module paths with SystemJS.
SystemJS.config({
  map: {
    "pkg-name":"dist",
    "lib":"dist", 
    ...
  },
  ...
});

[laurelnaiad]

( the branch above seems to work for paths and baseUrl. I can't get rootDirs to work, though it's not clear to me whether or not it's user error and/or the typescript compiler itself and/or something in atom-typescript which is at issue)

[laurelnaiad]

@krisdages since I notice you're using gulp-typescript and apparently interested in mapping support, you might be interested to find ivogabe/gulp-typescript#283, as well, a hack to get gulp-typescript to work with these attributes. So with the two PRs, I now have path mapping working in both atom-typescript and gulp-typescript (though I'm not using rootDirs).... (presently refactoring my code the way I've always wanted it to be, but couldn't have due to lack of path mapping)

[born2net]

anyone knows if path mapping via tsconfig already landed in ts@next as does not seem to work,

tx

Sean

[adamreisnz]

@born2net seems to work now with ts@next (1.9.0).

If you are using webpack with ts-loader though, make sure you also specify your path resolutions in the resolve config property, see TypeStrong/ts-loader#213

[born2net]

yes I know, I am using it and it's great:
https://github.com/born2net/studioDashboard

Angular 2 Kitchen sink: http://ng2.javascriptninja.io
and source@ https://github.com/born2net/ng2Boilerplate
Regards,

Sean

[adamreisnz]

Actually, it doesn't work in atom-typescript yet as it complains about invalid options:

But it's not complaining about missing imports, so as long as your compiler can handle it it's ok.

[webus]

+1

[born2net]

you have to upd to TS@next 1.9+

[webus]

I'm already on typescript@next and tslint@next. The problem only in atom-typescript plugin.

[born2net]

I understand, that plugin prob needs to be upd to @next, can you just override its package.json?

[webus]

You mean tsconfig in package.json ?

[adamreisnz]

Yes, but they are probably avoiding updating to an unstable/unreleased version, so we'll have to be patient or manually override as @born2net suggested.

@webus No, the package.json of the atom-typescript package inside your atom folder, so that that package uses the latest typescript@next.

[PatrickJS]

I got this working locally. In your atom Packages view this package (atom-typescript) then click on [View Code] then delete this line https://github.com/TypeStrong/atom-typescript/blob/master/dist/main/tsconfig/simpleValidator.js#L24

[mik01aj]

This bug was marked priority:high a year ago. There was a dozen of releases since then. Are you still planning on fixing it, or should we just monkey-patch that line as @gdi2290 suggests? 😢

[Goodwine]

It seems like the proper way to deal with this is to include every option from here
and there should be an option to set whether the plugin should ignore/warn/error these findings.

I suggest creating pull requests adding the options in this file (although I don't know if the repo owners want that)
https://github.com/TypeStrong/atom-typescript/blob/master/lib/main/tsconfig/tsconfig.ts

[mik01aj]

Why not use the official tsconfig parsing tool instead? I feel like just adding more options and workarounds isn't going to help in the long run.

[Goodwine]

I believe this is no longer an issue with the latest 11.x update

[guncha]

Yep, tsconfig.json should now support all the compiler options since we let it do all the work.

[GuskiS]

Hmm, I'm getting Cannot find module #shared/modules but TS compiles fine.

    "paths": {
      "#shared/*": ["shared/*"]
    }

[darksnow]

I'm in the same boat s GuskiS. TypeScript is working fine, atom is getting the completions from the imported objects so things appear to be working fine, but atom is complaining about my import { Class } from 'path_alias/filename';

[guncha]

Please create a test repo that shows the problem and I'll look at it.

[darksnow]

Looking into this a bit more and it's not you, it's the Linter that was pulled in as a dependency of atom-typescript.

Looks like this project is correctly identifying the code import, which is why things like auto completion are all working as expected. Sorry for the false flag.