New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

automatic module resolution for JPSM packages #6012

Open
Matthias247 opened this Issue Dec 9, 2015 · 96 comments

Comments

Projects
None yet
@Matthias247

Matthias247 commented Dec 9, 2015

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

This comment has been minimized.

Show comment
Hide comment
@mhegazy

mhegazy Dec 9, 2015

Contributor

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?

Contributor

mhegazy commented Dec 9, 2015

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

This comment has been minimized.

Show comment
Hide comment
@Matthias247

Matthias247 Dec 9, 2015

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 commented Dec 9, 2015

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

This comment has been minimized.

Show comment
Hide comment
@Matthias247

Matthias247 Dec 9, 2015

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.

Matthias247 commented Dec 9, 2015

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

This comment has been minimized.

Show comment
Hide comment
@vladima

vladima Dec 9, 2015

Contributor

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".

Contributor

vladima commented Dec 9, 2015

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

This comment has been minimized.

Show comment
Hide comment
@unional

unional Dec 12, 2015

Contributor

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).

Contributor

unional commented Dec 12, 2015

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

This comment has been minimized.

Show comment
Hide comment
@vladima

vladima Dec 13, 2015

Contributor

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)

Contributor

vladima commented Dec 13, 2015

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

This comment has been minimized.

Show comment
Hide comment
@unional

unional Dec 13, 2015

Contributor

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

Contributor

unional commented Dec 13, 2015

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

This comment has been minimized.

Show comment
Hide comment
@vladima

vladima Dec 13, 2015

Contributor

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.

Contributor

vladima commented Dec 13, 2015

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

This comment has been minimized.

Show comment
Hide comment
@unional

unional Dec 13, 2015

Contributor

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.

Contributor

unional commented Dec 13, 2015

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

This comment has been minimized.

Show comment
Hide comment
@dsebastien

dsebastien Dec 18, 2015

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

dsebastien commented Dec 18, 2015

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

@strabu

This comment has been minimized.

Show comment
Hide comment
@strabu

strabu Jan 4, 2016

+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.

strabu commented Jan 4, 2016

+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

This comment has been minimized.

Show comment
Hide comment
@giovannicandido

giovannicandido Jan 5, 2016

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

giovannicandido commented Jan 5, 2016

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

This comment has been minimized.

Show comment
Hide comment
@frederikschubert

frederikschubert Jan 8, 2016

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).

frederikschubert commented Jan 8, 2016

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

This comment has been minimized.

Show comment
Hide comment
@dougludlow

dougludlow Jan 10, 2016

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

dougludlow commented Jan 10, 2016

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

This comment has been minimized.

Show comment
Hide comment
@simonh1000

simonh1000 Jan 12, 2016

+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....

simonh1000 commented Jan 12, 2016

+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

This comment has been minimized.

Show comment
Hide comment
@rubyboy

rubyboy Jan 12, 2016

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.

rubyboy commented Jan 12, 2016

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

This comment has been minimized.

Show comment
Hide comment
@kunalbabre

kunalbabre Jan 15, 2016

Member
  • 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
Member

kunalbabre commented Jan 15, 2016

  • 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

This comment has been minimized.

Show comment
Hide comment
@byates-va

byates-va Jan 20, 2016

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.

byates-va commented Jan 20, 2016

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

This comment has been minimized.

Show comment
Hide comment
@unional

unional Jan 20, 2016

Contributor

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
Contributor

unional commented Jan 20, 2016

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

This comment has been minimized.

Show comment
Hide comment
@frederikschubert

frederikschubert Jan 21, 2016

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

frederikschubert commented Jan 21, 2016

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

@unional

This comment has been minimized.

Show comment
Hide comment
@unional

unional Nov 11, 2016

Contributor

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 jspm@0.17.0-beta.32

Contributor

unional commented Nov 11, 2016

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 jspm@0.17.0-beta.32

@jakeNiemiec

This comment has been minimized.

Show comment
Hide comment
@jakeNiemiec

jakeNiemiec Nov 11, 2016

@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

jakeNiemiec commented Nov 11, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@unional

unional Nov 11, 2016

Contributor

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

Contributor

unional commented Nov 11, 2016

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

@jakeNiemiec

This comment has been minimized.

Show comment
Hide comment
@jakeNiemiec

jakeNiemiec Nov 11, 2016

@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).

jakeNiemiec commented Nov 11, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@unional

unional Nov 11, 2016

Contributor

@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>

Contributor

unional commented Nov 11, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@sliultron

sliultron Nov 11, 2016

@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

sliultron commented Nov 11, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@unional

unional Nov 11, 2016

Contributor

@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).

Contributor

unional commented Nov 11, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@mythz

mythz Nov 28, 2016

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?

mythz commented Nov 28, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mhegazy

mhegazy Nov 28, 2016

Contributor

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.

Contributor

mhegazy commented Nov 28, 2016

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

This comment has been minimized.

Show comment
Hide comment
@blakeembrey

blakeembrey Nov 28, 2016

Contributor

@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.

Contributor

blakeembrey commented Nov 28, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@mhegazy

mhegazy Nov 28, 2016

Contributor

@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.

Contributor

mhegazy commented Nov 28, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@blakeembrey

blakeembrey Nov 28, 2016

Contributor

@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.

Contributor

blakeembrey commented Nov 28, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@mhegazy

mhegazy Nov 28, 2016

Contributor

would setting paths help with that?

Contributor

mhegazy commented Nov 28, 2016

would setting paths help with that?

@blakeembrey

This comment has been minimized.

Show comment
Hide comment
@blakeembrey

blakeembrey Nov 28, 2016

Contributor

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.

Contributor

blakeembrey commented Nov 28, 2016

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

This comment has been minimized.

Show comment
Hide comment
@aluanhaddad

aluanhaddad Nov 28, 2016

Contributor

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.

Contributor

aluanhaddad commented Nov 28, 2016

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

This comment has been minimized.

Show comment
Hide comment
@damiandennis

damiandennis Feb 5, 2017

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.

damiandennis commented Feb 5, 2017

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 nahuel referenced this issue Mar 6, 2017

Open

jspm (system) and npm @types #10047

2 of 2 tasks complete
@nahuel

This comment has been minimized.

Show comment
Hide comment
@nahuel

nahuel Mar 6, 2017

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/.

nahuel commented Mar 6, 2017

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

This comment has been minimized.

Show comment
Hide comment
@atrauzzi

atrauzzi Mar 7, 2017

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

atrauzzi commented Mar 7, 2017

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

@aluanhaddad

This comment has been minimized.

Show comment
Hide comment
@aluanhaddad

aluanhaddad Mar 7, 2017

Contributor

@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.

Contributor

aluanhaddad commented Mar 7, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@atrauzzi

atrauzzi Mar 7, 2017

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?

atrauzzi commented Mar 7, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mythz

mythz Mar 10, 2017

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.

mythz commented Mar 10, 2017

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

This comment has been minimized.

Show comment
Hide comment
@unional

unional Mar 10, 2017

Contributor

@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).

Contributor

unional commented Mar 10, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@mqudsi

mqudsi Apr 20, 2018

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?

mqudsi commented Apr 20, 2018

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

This comment has been minimized.

Show comment
Hide comment
@jakeNiemiec

jakeNiemiec Apr 20, 2018

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

jakeNiemiec commented Apr 20, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment