Typescript: 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/[email protected]/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:[email protected]",
  ...
  }
});

This means if we can locate this file and parse it we know that import 'angular2/x' points to jspm_packages/npm/[email protected]/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

[byates-va]

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.

[masaeedu]

IMHO we should work towards implementing something that conforms to the https://whatwg.github.io/loader/ spec, since this is implemented by the loader polyfill used by SystemJS, and by proxy JSPM. If we follow that we get JSPM compatibility now, and hopefully when the loader spec solidifies we'll get compatibility with that as well for free, or with the expenditure of minimal work.

[jonaskello]

@masaeedu I think that is already possible if you use system as output module format for tsc. The issue is about resolving import 'name'to the path where 'name' can be loaded from.

[masaeedu]

@jonaskello Using system as the output module format doesn't affect module resolution. What I'm suggesting is that we follow the module _loader_ spec, which allows custom module loaders that follow the spec (such as SystemJS) to be used for module resolution by the compiler.

[jonaskello]

@masaeedu SystemJS uses config.js and resolves through System.config.map. Currently we need to copy the path info from config.js to tsconfig.json to make it work with tsc. I thought the spec was only about standardizing loading and did not mandate resolution through System.config.map. Could you point to where it is mentioned?

[masaeedu]

@jonaskello I'm getting a bit out of my depth here, but my understanding is that es6-module-loader (which is what SystemJS, and therefore JSPM use under the hood), is a particular implementation of a more general ES specification for users to configure how module names are resolved and loaded. You can see a much earlier attempt at implementing the specification here: https://github.com/jorendorff/js-loaders/blob/master/browser-loader.js.

The idea is that we can use this (hopefully-soon-to-be) standard API to resolve modules, and simply let other code (such as SystemJS) configure the module resolution scheme as it pleases. I don't think copying information out of config.js into tsconfig.json and trying to re-implement SystemJS's module resolution scheme is a good idea.

Perhaps @guybedford can provide more information/clarify anything I'm getting wrong.

[jonaskello]

@masaeedu The closest I could find in the spec is this: https://whatwg.github.io/loader/#properties-of-the-browser-loader-prototype. It says "TODO: name resolution policy" so maybe the resolution of name to paths will eventually be included in the spec. Maybe someone with insight into the spec can shed some light on if it is the intention to have resolution as part of the spec, or if the spec only intend to enable custom resolution logic. I think what JSPM does today is custom logic that is not part of the spec.

[masaeedu]

@jonaskello A specific module resolution strategy will not be part of the spec. The intention is to allow module resolution strategies to be configured, then consumed via a uniform API.

So for example when TypeScript wants to determine the canonical name of a module it should do loader.normalize(relativeModuleName), and when it wants to obtain the contents of a module it should do loader.fetch(moduleURL). In those snippets loader could be System (for the JSPM use case we're considering), or a custom loader implementation, or (in the future) a runtime dependent builtin implementation (for CJS, file based resolution in Node and HTTP based resolution in the browser).

We would need a tsconfig option that allows a loader instance to be bootstrapped and somehow exposed to TypeScript, but from that point on the internals of the loader instance dictate how modules are actually resolved.

[jonaskello]

@masaeedu Yes, I agree that having a resolution plugin for tsc would be the best solution. It was already suggested above but from the discussion it seems that the work involved is too big so we are stuck with the copy from config.js to tsconfig.json solution for now. However it works for the compiler API, which is how plugin-typescript makes resolution work for JSPM. I think this issue will not be fully solved until the work involved in making the module resolution pluggable in tsc is done. However not sure this work is even planned?

[unional]

Chiming in. Basically just repeating what @jonaskello said :smirk:

If taking a jspm-loader route, does the loader system allows interaction between loaders? How will ts-loader or babel-loader interact with jspm-loader? They are orthogonal and need to work together.

[masaeedu]

@unional Yes, you can simply write a loader that delegates to all of those other loaders in the implementation. This is essentially what SystemJS does with its plugins.

[guybedford]

If you're looking for API proposals here, the resolve API in the loader itself looks something like:

resolve(request, resolvedParent)

Where the resolve method can return a direct resolved string, or a Promise.

If the compiler allowed this resolve method / hook to be specified through options, then the jspm resolver could be hooked in via:

options.resolve = require('jspm').normalize;

The resolution space could be absolute file system paths, or as SystemJS uses, file:/// URLs.

[guybedford]

The other side of such an API would be to also look at offering "fetch", "translate" or "instantiate" hooks as well.

[masaeedu]

options.resolve = require('jspm').normalize;

@guybedford Wouldn't you need locate instead of normalize there?

[guybedford]

@masaeedu the locate hook is deprecated for a single resolve operation that provides the absolute URLs / paths.

[mikekidder]

Curious that, on a little test I setup, VSCode editor is recognizing zone.js and reflect-metadata via the jspm_packages folder, but not angular2 modules. I've only setup and installed via jspm, not npm.

[Jefftopia]

@mikekidder Also curious, I'm using JSPM and Angular 2 on VSCode and encountering _no_ compilation issues.

[mikekidder]

@Jefftopia ended up just going with Angular2, TS, Systemjs as per the quickstart. Actually have similar working with React, TS, Systemjs, Mobx.. works well for me in VSCode

[Jefftopia]

@mikekidder I haven't tried it yet, but TypeScript added support for JSPM. It's not in the production branch through, and won't be until 2.0. You get get it now if you install typescript@next.

See here: https://github.com/Microsoft/TypeScript/pull/5728

[masaeedu]

@Jefftopia That adds support for path mappings, which means you have to manually copy all the mappings from your config.js file to your tsconfig.json file. JSPM does not have first class support.

[Cedware]

+1, I think cs code can handle this, so it should work for typescript to

[Nek-]

I tried typescript@next. rootDirs options didn't helped my at all. The point is that the missing option for jspm is not include files or something, it's moduleResolution.

Why ? Because we all have module declaration duplicated in third party libs.

Well, I say it didn't help me but maybe it's because I don't really know how to work typescript. So correct me if i'm wrong. I tried things like this:

{
    "compilerOptions": {
        "target": "es5",
        "module": "system",
        "moduleResolution": "classic", // as `node` is only for node_module I removed it
        "sourceMap": true,
        "emitDecoratorMetadata": true,
        "experimentalDecorators": true,
        "removeComments": false,
        "noImplicitAny": false
    },
    "rootDirs": [
        "web/jspm_packages"
    ],
    "exclude": [
        "node_modules",
        "web/jspm_packages",
        "web/build",
        "typings/browser.d.ts",
        "typings/browser",
        "vendor"
    ]
}

[aluanhaddad]

Annoying, but I still find the benefits of jspm to outweigh the annoyance of having to manually specify as @giovannicandido does. That said, I would love to see better integration, but I would not let go of either TypeScript or jspm because of this issue.

[frankwallis]

@Nek- I think the config needs to look like this: https://github.com/frankwallis/plugin-typescript/blob/master/examples/angular2/tsconfig.json

[aluanhaddad]

I would love to see this implemented, but I understand the difficulties. I still find using TypeScript, JSPM, and SystemJS together to be an excellent experience.

[dmiorandi]

+1

I'm using Typescript, JSPM+SystemJS. I'm also intrested on this. Actually I need on some modules to install both in jspm (runtime) and in npm (compile Typescript only) this is awesome

[playground]

+1 would be ideal if IDE can resolve import by looking into jspm_packages instead of node_modules.

[j2L4e]

I found sym-linking the needed packages to be an easy workaround.
Not pretty, but for the time being it's getting the job done.

This prints out the ln commands to link directories in jspm_packages/npm/ to node_modules/ pick those you need (the command below is not linking anything automatically).

cd <your project root>
for f in $(ls -d jspm_packages/npm/*/)
do echo "ln -s ../$f node_modules/$(echo $f | grep -o '\/[^\/@]*@' | grep -o '[^\/@]*')"
done

edit: As of rc0 this snippet isn't going to work for angular anymore. However linking e.g jspm_packages/npm/@angular/[email protected] to node_modules/@angular/core still gets the job done.

[sundriver]

+1

[refresh09]

Instead of waiting for "paths" support in the Typescript 2.0 tsconfig, the same thing can be done using typings.

typings install --save @angular/core=file:../jspm_packages/npm/@angular/[email protected]/index.d.ts

or directly in typings.json

{ "name": "", "dependencies": { "@angular/core": "file:../jspm_packages/npm/@angular/[email protected]/index.d.ts" } }

[born2net]

as mentioned, I don't mind specifying the entry in tsconfig as well, the issue becomes when you have to reference a @build.x.y under Paths per lib, and so on every update you have to go and manually updates build numbers in both tsconfig as well as in jspm.config.js and or packages.json

[unional]

@born2net Not only that, a bigger issue with paths is that it does not follow dependencies.

Say packageA depends on packageB (and I only use packageA), I have to specify both of them in paths to make it work correctly:

// tsconfig.json
{
  "paths": {
    "packageA": [
      "jspm_packages/npm/[email protected]/dist/"
    ],
    "packageB": [
      "jspm_package/npm/[email protected]/dist/"
    ]
  }
}

This means you have to manage the whole dependency tree manually.......

EDIT:
And then it also means that you can't have version mapping. What if packageA depends on [email protected] and packageC depends on [email protected]?

[born2net]

ouch...

[amcdnl]

@refresh09 does that config work for you? I'm doing it here and not having much luck w/ it. https://github.com/swimlane/angular2-data-table/blob/master/tsconfig.json#L25

@unional does it follow npm dependencies correctly? If so, TS team could just sniff the package.json config for jspm and trace from there.

[unional]

Yeah, that's what I need to do on typings

[glen-84]

It should probably be a generic solution, and not a solution specific to jspm or any other package manager. Would something like:

moduleResolver: "/path/to/module/resolver(.js?)"
// e.g. "node_modules/jspm-module-resolver/index.js"

... be possible? Where TS loads the script/module and invokes a method passing it the relevant information (module name to resolve, context, etc.), and the "resolver" returns the appropriate data.

Then anyone can write a resolver, package managers could expose their resolver, and you could even create resolvers capable of resolving from multiple locations/fallback resolvers.

I'm probably missing something obvious that makes this a lot more difficult in practice.

[unional]

jspm-config is such as resolver for typings. However, to make it useful and efficient for TypeScript hook, the resolver need to be a class containing states, not a resolve(pkgName: string): DependencyTree function.

This is because, for the case of jspm, all dependencies are read together. It doesn't make sense to read package.json and jspm.config.js multiple times for each dependency.

[aluanhaddad]

@unional could you explain in more detail why it has to be a class? If the resolver needs to be stateful, wouldn't a closure work just as well?

[unional]

A closure can work. However, you don't have control of the initialize process in this case. I would avoid not controllable code making access to external dependencies (file system in this case) when possible. IMO it offers much better maintainability and testability.

[MarcinGil]

+1. Need this as well.

[sliultron]

+1. Need this as well.

[glen-84]

@sliultron Please use reactions now, instead of +1 comments.

[unional]

typings 2.0 just released and support of jspm has landed.
Before a solution (and perhaps merging effort) is available in TypeScript, you can give it a try.

jspm install <package that distribute package.json and typings in jspm>
typings install jspm:<that package name>

e.g.

jspm install npm:make-error
typings install jspm:make-error

[jakeNiemiec]

@unional is typings still relevant now that we have types publisher aka @types(https://www.npmjs.com/~types & https://github.com/Microsoft/types-publisher) ?

[unional]

It does, as there are still some features missing on @types.

In the future the will be a consolidation between the two https://github.com/Microsoft/types-publisher/issues/4

However, for jspm support, what I added in typings is better IMO because it supports renaming and other goodies provided by jspm.

Currently, if the typings is bundled within the source package, without typings you have to install the package to both jspm and npm.

[plgregoire]

@unional
I tried using typings 2.0 but

jspm install npm:make-error-cause
typings install jspm:make-error-cause

gave me this error
Unable to resolve "jspm:make-error-cause" from "make-error-cause"

any idea why ?

[unional]

Ah, sorry, wrong example. make-error-cause actually does not have typings in the package. You can try make-error. make-error-cause stucked in my mind because it's one of the packages I used for testing.

Updated the previous comment.

[plgregoire]

Still not working...
I always get this error no matter what I write as package name

> typings install jspm:make-error
typings ERR! message Unable to resolve "jspm:make-error" from "make-error"
typings ERR! caused by Cannot read property 'browser' of undefined

Maybe it is related to file structure of my project or the configuration of jspm.
I will keep trying...

[jakeNiemiec]

@plgregoire I suggest just installing the @types/xyz package to both jspm and npm and be done with it. There was a time where I would have fought with my tooling to get it to work the way it should. But, in reality, sometimes its best to sit back, and wait for the next version.

[plgregoire]

I like the chart very much :) Thanks for the advice
However, it is already how I am set up: packages in both jspm and npm. I can live with that but when I heard that it may be an alternative now, I had to try it.

[unional]

That's strange. I don't have any problem with it.

Can you share your setting so I can take a look into it? You can open a PR on typings to keep track of it here. 🌷

[unional]

Ar, I can see the error you have. You are using jspm 0.16. I was working on this using 0.17. The config is very different.

[plgregoire]

You're right.
I will try upgrading to jspm 0.17.
Thanks a lot.

[unional]

At the moment, 0.17 is still in beta, so you can just try it out on a toy project. It is long due.... 😛 .

I found one problem and fixing it right now. Just like @jakeNiemiec graph is saying. 😜
Since jspm 0.17 is still in beta, I guess something might have changed. 😭 .

To try out what I mentioned, you can do:

jspm init
jspm i npm:make-error
typings i jspm:make-error

Somehow running jspm i npm:make-error without jspm init produces different config file. 😞

UPDATE: nevermind, that bug seems to be fixed in [email protected]

[jakeNiemiec]

@unional Don't get me wrong, I appreciate the work typings accomplishes; however, the problem is when tooling is interacting with tooling. It probably wasn't made for that in mind, and never will.

jspm however is highly versatile, just make a PR to https://github.com/jspm/registry to accommodate the specifics of installing/using make-error.

e.g. for babel: https://github.com/jspm/registry/blob/master/package-overrides/npm/babel-core%405.0.0.json

[unional]

@jakeNiemiec thanks. What does your example do? I'm a bit confused.

[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/[email protected]
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/ [email protected]/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 :(
~json
"@angular/common": "file:jspm_packages/npm/@angular/[email protected]",
"@angular/compiler": "file:jspm_packages/npm/@angular/[email protected]",
"@angular/core": "file:jspm_packages/npm/@angular/[email protected]",
"@angular/forms": "file:jspm_packages/npm/@angular/[email protected]",
"@angular/http": "file:jspm_packages/npm/@angular/[email protected]",
"@angular/platform-browser": "file:jspm_packages/npm/@angular/[email protected]",
"@angular/platform-browser-dynamic": "file:jspm_packages/npm/@angular/[email protected]",
"@angular/router": "file:jspm_packages/npm/@angular/[email protected]",
~

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: https://github.com/systemjs/systemjs/issues/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