Repository navigation
automatic module resolution for JPSM packages #6012
Description
Activity
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?
I'm not sure if it would work.
From my projects root directory the path to angular2 isjspm_packages/npm/[email protected]/angular.(js|d.ts)
If i would set a rootdir tojspm_packages/npm/thenimport '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 importingangular2. Then typescript would probably be happy - but SystemJS would no longer find the module.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 tojspm_packages/npm/[email protected]/x.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".
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).
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)
Indeed. From what you are saying, is it correct that in order to have editor support (
webStorm,atomVS Codeetc) resolving jspm packages correctly, we need to either:- Complete the command line compiler backlog item, or
- Editors can use the compiler API to implement the proper resolution
Is 2 possible?
Thanks,
UniIn 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.
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.
+1, this is really pushing me to consider letting go of JSPM :(
+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.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#34407887My 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:
- Manual edit declaration files, there is no way to generate the files automatically in this shape
- 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
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).
71 remaining items
Mohamed Hegazy (@mhegazy) No worries, thanks. I just thought you had misread from your comment being explicitly about
@typespackages. 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.would setting
pathshelp with that?Good point, sounds like that should work by combining
npm install(for the package) and TypeScriptpaths(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.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 (@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.
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/[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 (@type) npm libraries as well I am fairly sure.
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 onlynode_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 usejspm_packages/at all, but make SystemJS compatible withnode_modules/.Yeah, definitely agreeing with this. Ecosystem needs to come together and I would love for JSPM & SystemJS to play nicely.
Alexander Trauzzi (@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.
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?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.
Demis Bellot (@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).Reacted by Demis BellotHas 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?
Mahmoud Al-Qudsi (@mqudsi) you have this coming down the pipeline: https://github.com/nodejs/modules
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.
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.