search

jspm / registry

The jspm registry and package.json override service
https://jspm.io
229 stars 256 forks source link

fix back compatibility with jspm 0.16 #1041

Closed frankwallis closed 7 years ago

frankwallis commented 7 years ago

see https://github.com/Microsoft/tslib/issues/26#issuecomment-284441324

There is an issue with pointing at the ES module file because not everyone is using a transpiler.

I had to add "esModule": true to make it work with SystemJS@0.20, it seems that commonjs module.exports is hidden behind the 'default' property otherwise, which didn't seem correct to me. Shouldn't it be possible to import module.exports directly without using 'default' or setting 'esModule'?

aluanhaddad commented 7 years ago

We could import it using

import * as tslib from 'tslib';

and from a TypeScript perspective that might be expected to work but my understanding of SystemJS@0.20 and the node eps is that the semantic implications of this are invalid and that it is therfore not allowed. @guybedford any insight on this would very helpful.

aluanhaddad commented 7 years ago

As this is now broken again for jspm@0.17, I am trying to find and test a solution that will work for both branches.

guybedford commented 7 years ago

@aluanhaddad the alternative to __esModule set in the original source is to add a meta configuration:

"meta": {
  "tslib.js": {
    "esModule: true
  }
}

this should work through the jspm 0.17 metadata override mechanism, as it passes all meta options directly to SystemJS (even though this was a recent SystemJS addition).

Let me know if that can work for you.

aluanhaddad commented 7 years ago

@guybedford Excellent. I was not aware of the "esModule": true setting. Thank you.