automatic module resolution for JPSM packages

[Matthias247]

I'm trying to use angular2 as a JSPM package.
When I'm doing something like
import {bootstrap, Component, Input} from 'angular2/angular2';
in my code then typescript complains that it can't find the definitions and I don't get any code completions.

The workaround is to install angular2 also as a npm package and set moduleResolution to node. However this seems not optimal, because now I have two dependencies whose versions need to be aligned.

I guess tsc could resolve the modules for jspm/systemjs similar to how it already can do it for node. E.g. look up package.json, config.js and use the pathes from there the locate to type definitions inside the jspm_packages folder.

Not really sure if this is covered by #5039 and #5728.

[mhegazy]

JSPM resolution does not seem to be a simple task to do statically. #5039 should allow you to add to the configuration an override for resolving angular2, would that be sufficient?

[Matthias247]

I'm not sure if it would work.
From my projects root directory the path to angular2 is jspm_packages/npm/angular2@2.0.0-alpha.50/angular.(js|d.ts)
If i would set a rootdir to jspm_packages/npm/ then import 'angular2/angular2' would stil not work because the version number is inserted by JSPM.
Setting the rootdir to include the version number would require only importing angular2. Then typescript would probably be happy - but SystemJS would no longer find the module.

[Matthias247]

Where do you see problems with static resolution?
JSPM creates a SystemJS config file which contains all the necessary information:

System.config({
  baseURL: "/",
  defaultJSExtensions: true,
  transpiler: "none",
  paths: {
    "github:*": "jspm_packages/github/*",
    "npm:*": "jspm_packages/npm/*"
  },
  map: {
    "angular2": "npm:angular2@2.0.0-alpha.50",
  ...
  }
});

This means if we can locate this file and parse it we know that import 'angular2/x' points to jspm_packages/npm/angular2@2.0.0-alpha.50/x.

[vladima]

the difference between node module resolution and JSPM is that node rules are exactly specified whereis JSPM resolution logic can only be reconstructed from the implementation (and implementation has several augmentations during the last year). I can see TypeScript having support for JSPM module resolution after it will be stabilized and specified otherwise there is a risk that TypeScript will always be one step behind chasing down SystemJS and this will be an endless source of issues with the same origin "TypeScript cannot find something that SystemJS can".

[unional]

Would it be possible to specify a resolution plugin and the plugin implementation is managed by jspm or someone closer on that end?

I have the same need (as everyone using typescript with jspm should).

[vladima]

currently module resolution is customizable if you use compiler API, we don't support loading user defined resolvers when using command line compiler. This is something that we have in our backlog but the size of this workitem is quite large (it should just work not only in command line compiler but also in all editors we officially support)

[unional]

Indeed. From what you are saying, is it correct that in order to have editor support (webStorm, atom VS Code etc) resolving jspm packages correctly, we need to either:

1. Complete the command line compiler backlog item, or
2. Editors can use the compiler API to implement the proper resolution
   Is 2 possible?

Thanks,
Uni

[vladima]

In theory it is possible however keep in mind module resolution in editor and in compiler should be consistent otherwise we'll get quite annoying behavior when compiler cannot find some module that editor can discover just fine and vice versa.

[unional]

Agree. Currently that is exactly what annoys me as systemjs/jspm can discover and run application correctly but the editor and tsc command line compiler cannot.

[dsebastien]

+1, this is really pushing me to consider letting go of JSPM :(

[strabu]

+1, Agree, modules from jspm_packages should be resolved by TSC and the editors.
Otherwise JSPM and it's bundling-workflow would be dead for Typescript-users.

[giovannicandido]

To put my two cents on the discussion:
http://stackoverflow.com/questions/33702567/how-to-import-external-npm-module-with-typescript-declarations-using-jspm/34407887#34407887

My work around is to create definitions files for the jspm library with a top level declaration module for instance:

File notify.d.ts

declare module 'common/notify' {
export declare class Notify {
}
}

File common.d.ts

declare class Common {
}

File components/ca.d.ts

declare module 'common/components/ca' {
  export declare class Bla {
  }
}

That way a import for 'common/components/ca' is resolved

import Bla from 'common/components/ca'

Problems:

1. Manual edit declaration files, there is no way to generate the files automatically in this shape
2. common could be override in the Systemjs system. The developer must install the library in the form jspm install common=github:/bla/bla if there is a name clash with other library, no luck here.

I wish the javascript module community had put the pride beside and had learned something with old dog java, and have made that thing less cumbersome. Java import's are way more stable and predictable, not ideal, and for sure not the best, but work very good with external libraries.

The javascript module standards forget distribution and package as a crucial design