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

[frederikschubert]

I would love to see this feature implemented as its the only thing that needs a workaround in our Angular 2 setup (apart from the hopefully soon released jspm 0.17).

[dougludlow]

Link to an issue on stackoverflow that show's what we get in vscode and visual studio 2015 because typescript doesn't know how to resolve jspm packages:

http://stackoverflow.com/questions/34462132/vs-code-cant-use-jspm-packages-systemjs-cant-see-angular2-ts-files

[simonh1000]

+1 - this is really a pity as it felt that systemjs was the anointed package manager for Angular2, together with Typescript, but if they don't all play nicely together....

[rubyboy]

Would definitely like to see this solved.
JSPM is awesome!! So we're unwilling to give up on it :)

FWIF, it's still possible to use it properly with a bit of a workaround. To add to the one described by @giovannicandido above, we are using a combination of the Typings project (formerly TSD) and npm. This is only required for development time IDE support. Check out our angular2-redux-example example project for details. Run "npm install" and "npm typings" to get all types to be recognised properly in your IDE.

[kunalbabre]

• 1, I was working with a team that uses JSPM, however, this issue causes poor experience using JSPM. One of the workarounds is to use https://github.com/frankwallis/plugin-typescript however, it means you almost cannot compile or use intellisense on IDE

[brentyates]

Our team/company has run up against this issue as well. We've been evaluating all of our options for frontend package management, and it really is JSPM that seems to be the best fit for our needs. However, we feel that we get more out of typescript, especially the IDE features, than we do out of the JSPM package management, which due to this issue means not using JSPM. We are damned if we do, damned if we don't, we either get to use our best option for development at the cost of our best package management option, or vise versa.

We have also experimented with the workaround suggested earlier, where we continue to use JSPM but also install via NPM for the IDE side. Then we either wait until this issue is addressed, or ideally help develop a solution. Once the solution is in place, we remove the need to install the duplicate package just for the IDE support.

I mostly wanted to weigh in to see if anybody has any work started on this that we could help contribute to, or if at this point we are best off starting our own experiments to address this, either something that works just for our company's workflow, or an actual PR to the community to help address it for everyone.

EDIT: I can see that I have a lot of reading to do in the other two linked issues, as at least the first one is a formal proposal as to how this might work. This is good to see.

[unional]

As @mhegazy adds "needs proposal" to this thread, we can discuss on how to get this done.

To summarize, there are three parties that needs module resolution:

• Running system inside jspm: This is done through plugin-typescript, and is working (Transpliation in jspm will be deprecated and solely rely on plugins)
• Transpiling code using tsc that uses modules in jspm_packages
• IDE support: Best way is to support through typings/tsd, so there is no need to support individual IDE

[frederikschubert]

I thought that this PR would solve the problem for the tsc part but maybe I misunderstood.

[jakeNiemiec]

@unional It universally configures a package for jspm. Here are docs for how it works: https://github.com/jspm/registry/wiki/Configuring-Packages-for-jspm

If you have any other questions feel free to email me (I don't want to clog up everyones notifications).

[unional]

@jakeNiemiec thanks. If I have other questions, will email you on that.
However, I don't see how that would relate to the OP here, thus my confusion.

The problem is we need to provide tsc and ts language service the typings needed.
Duplicating the installation of the package on both jspm and npm is one way, and using typings install jspm:<pkg> with jspm install <pkg> is another.

If the typings is in @types it is a bit nicer as it is light-weight, but installing package with typings in both places is not as desirable.

Also, @types solution cannot handle package mapping, AFAIK. So if you use that feature in jspm then you are stuck. However typings supports that: typings i <mappedName>=jspm:<pkg>

[sliultron]

@unional
I was tyring this with jspm 0.17 beta
jspm install npm:angular
typings install jspm:angular

however, the index.d.ts does not exist in the jspm_packages/npm/angular@1.5.8
seems most packages installed with jspm do not have index.d.ts included.

please advise

thanks

[unional]

@sliultron , typings install jspm:<pkg> is for the package that distributes typings with it. For packages that do not distribute typings such as angular, you have to use either @types or typings install <pkg> (which does not have angular, so stay with @types).

[mythz]

Would be great if TypeScript either maintained first-class support for JSPM and included it as part of their Q/A or developed/maintained their own JSPM-like module management so we could get an integrated solution for installing, referencing and bundling TypeScript modules. After multiple tsd, typings and now @types solution rewrites we still don't have a good story for publishing, installing, referencing and bundling TypeScript modules.

Currently TypeScript can't use definitions that are bundled with the package and installed with JSPM. So package authors are forced to maintain a parallel @types definition by making pull requests to a central repository (with slow turn around times) in order to publish our modules definitions that are also maintained alongside the TypeScript module in our npm package.

If TypeScript isn't going to have first-class support for JSPM, what's the recommended dev workflow for referencing and bundling TypeScript modules? Should we reference every npm package we want to use in .html pages manually and then install/configure a separate tool like Webpack to bundle it?

[mhegazy]

what's the recommended dev workflow for referencing and bundling TypeScript modules?

My recommendation is to add a devDepenency to the @types packages you are using. this will allow the compiler to find the declaration at compile time.

[blakeembrey]

@mhegazy I think you may have missed the gist of the comment you quoted. It's talking about packages with native type definitions and not @types packages that are installed with JSPM. Currently they have to maintain both npm install and jspm install in sync to get TypeScript to work.

[mhegazy]

@mhegazy I think you may have missed the gist of the comment you quoted. It's talking about packages with native type definitions and not

sure. i do not see them different, really. you can have a devDepenency on these as well just for type declarations.

Currently they have to maintain both npm install and jspm install in sync to get TypeScript to work.

that is correct, since the compiler does not understand JSPM modules naively , and this is what this issue is tracking. ideally the compiler will do this for you. but mean while you can add a devDepenency.

[blakeembrey]

@mhegazy No worries, thanks. I just thought you had misread from your comment being explicitly about @types packages. There's a small amount of overhead of maintenance with the duplication approach and duplicating, I had assumed, was already the only approach possible. The only thing not possible, I believe, with the duplication approach is that JSPM supports module aliases. I don't think there's an easy way to do that with NPM.

[mhegazy]

would setting paths help with that?

[blakeembrey]

Good point, sounds like that should work by combining npm install (for the package) and TypeScript paths (for the alias). I believe this wouldn't remove the original module which doesn't exist, but sounds usable0. Sorry, I don't use JSPM myself, just find myself answering the questions a lot so that knowledge is helpful. Cheers 👍

Side note: The handbook font sizing really shouldn't use ems. They compound and have giant text for list items. I'll find the right place to log this.

[aluanhaddad]

Paths work for aliasing certain modules but they are difficult to maintain and only a partial solution as they fail on constructs like

/// <reference types="dependency" />

Because we can redirect the directory structure to point at the packages folder but cannot alias the actual reference because it's an @types reference.

That said, the real difficulty is in maintaining all the versionsed paths. It would be helpful if we could specify wildcards in "paths" to match prefixes instead of entire names.
For example it would be great if

{
  "paths": {
    "moment" : [
      "jspm_packages/npm/moment*/index"
    ]
  }
}

could be used to match "jspm_packages/npm/ moment@m.m.p/index".

It's only a solution because it doesn't deal with the transitive dependency issue that jspm solves but it would go a long way in making a lot of scenarios easier.

[damiandennis]

Adding this to my devDependencies in package.json worked for me. Only problem is you have to be specific on the package names :(

"@angular/common": "file:jspm_packages/npm/@angular/common@2.4.6",
    "@angular/compiler": "file:jspm_packages/npm/@angular/compiler@2.4.6",
    "@angular/core": "file:jspm_packages/npm/@angular/core@2.4.6",
    "@angular/forms": "file:jspm_packages/npm/@angular/forms@2.4.6",
    "@angular/http": "file:jspm_packages/npm/@angular/http@2.4.6",
    "@angular/platform-browser": "file:jspm_packages/npm/@angular/platform-browser@2.4.6",
    "@angular/platform-browser-dynamic": "file:jspm_packages/npm/@angular/platform-browser-dynamic@2.4.6",
    "@angular/router": "file:jspm_packages/npm/@angular/router@3.4.6",

It would work similar for any @type npm libraries as well I am fairly sure.

[nahuel]

You can use https://github.com/charto/cbuild to create a SystemJS bundle from node_modules/
There is also work here to make SystemJS use only node_modules/: https://github.com/alexisvincent/systemjs-tools/blob/master/docs/features.md#node_modules-package-resolution-beta
I think the best option long term is to not use jspm_packages/ at all, but make SystemJS compatible with node_modules/.

[atrauzzi]

Yeah, definitely agreeing with this. Ecosystem needs to come together and I would love for JSPM & SystemJS to play nicely.

[aluanhaddad]

@atrauzzi I really want to see this. Is there something in JSPM specifically that you feel is out of balance here? From my point of view, the versioned folders approach has a lot of advantages. The primary disadvantage is in fact the impedance mismatch between JSPM and TypeScript but I would appreciate any thoughts you might have on things that could be improved on the JSPM side as they pertain to this issue.

[atrauzzi]

The biggest problem is going to be that JSPM isn't the same final structure as nodejs and that has loader implications. Implications that most tooling has now come to agree are the one true way.

In the past, anything that tries to compete with a community recognized standard has typically lost. Quite soundly. If we look at why and how in this specific case, we have to understand that both JSPM and TypeScript are subsets of the nodejs community overall.

But yeah, I entirely agree, JSPM got a lot of things right. But we have yarn now, and we've got node_modules, and it almost seems like the book is closed on the whole topic...for now?

[mythz]

When it works JSPM is great so it would be a shame if JSPM remained unsupported. It appears the latest jspm@beta has broken integration with TypeScript again and after wasting some time permutating through different configurations I've had to pin it to an older version of jspm@beta.

It would be nice to see some clarification from the TypeScript team if JSPM is going to be a supported configuration and if there are plans to provide native support and get some much needed Q/A love? or if the TypeScript team are focusing on a different supported configuration and what the recommended configuration should be? i.e. npm/webpack?

It would help in deciding which approach to adopt that's well supported and will continue to work in future.

[unional]

@mythz FYI it is probably due to this: systemjs/systemjs#1587
And we are at a fork here on how to get TS to work with JS moving "backward" (interop with CommonJS).

[mqudsi]

Has the situation changed in the past year? I see the proposal for resolution plugins was closed, and the preference is to simply work with SystemJS "out-of-the-box". Is there another issue I can track or that blocks this?

[jakeNiemiec]

@mqudsi you have this coming down the pipeline: https://github.com/nodejs/modules

[RyanCavanaugh]

JSPM seems to have gone quietly into that good night (Google Trends graph below), so I don't think this is likely to ever be a priority for us now.