Integrate new typescript module resolution

[frederikschubert]

As this PR is now merged in typescript@next it would be nice to set the baseUrl and path mappings in the tsconfig.json when installing a module. This information is already present in the jspm.config.js and can easily be copied I think.
This way it would be just as easy to use the typings that a module ships with it, as it is now to import the library with jspm.

[jonaskello]

+1 for somehow integrating this! I did some testing and I could not make it work by just copying but with the right entries for baseUrl and paths in tsconfig.json it is now possible to for tsc to consume embedded typings from npm packages installed by jspm. (Works with typescript@next).

[frederikschubert]

Apart from this issue I got it working fine. Here is my tsconfig.json:

{
    "compilerOptions": {
        "emitDecoratorMetadata": true,
        "experimentalDecorators": true,
        "outDir": "tmp",
        "target": "es5",
        "module": "commonjs",
        "moduleResolution": "node",
        "removeComments": false,
        "sourceMap": true,
        "baseUrl": "./jspm_packages",
        "paths": {
            "angular2/*": [
                "npm/angular2@2.0.0-beta.1/*"
            ]
        }
    },
    "exclude": [
        "node_modules",
        "jspm_packages"
    ]
}

To enable this in VSCode you can add this snippet to your workspace settings.

{
    "typescript.tsdk": "node_modules/typescript/lib"
}

[guybedford]

//cc @frankwallis

[jonaskello]

I also got it to work with a private git package I have which have embedded typings. Although it is not possible to just cut and paste from config.js but in trivial cases it is close.

[guybedford]

This is not a jspm concern unfortunately, and would be unnecessary coupling.

[jonaskello]

I can see how it is not a jspm concern, also I can see how it is not a typescript concern. So the situation becomes a bit unfortunate as the only solution left is to build a third tool that looks up the information in config.js and fills in tsconfig.json. Another solution could be possible if there is some integration point in jspm or tsc we could use. Any suggestions?

[guybedford]

@jonaskello wrapping the typescript build with jspm support through a small third-party project does sound like the correct way forward.

[jonaskello]

The way I currently think about it is this:

1. The config.js contains the "master" mappings of modules.
2. The typescript compiler (tsc) needs the same mapping information in a slightly different format in the tsconfig.json file.
3. The config.js file is only updated when we run jspm install/uninstall (may not be true?).
4. Since tsconfig.json only needs to be updated when config.js is updated, this would mean that the logical place to do this update would be on jspm install/uninstall.
5. So wrapping jspm install to make this happen would make more sense than wrapping the typescript build process. (Given the build will happen each time you change something in the source rather than when you install new packages).

However, not sure if all those items are true so my logic might be flawed :-). Anyway I guess my question is if we can extend jspm install with thirdparty logic somehow?

[guybedford]

Thanks, that's making a lot of sense. How about a simple CLI tool like jspm-tsc-update work here:

  jspm install x && jspm-tsc-update

Where it then updates the tsconfig.json file from the jspm config file?

[jonaskello]

Yes that makes sense. One step further would be if we could automatically execute a script after each "jspm install x". Npm will automatically run some predefined scripts from the scripts section of package.json after a certain command is issued. For example it will run the script "postinstall" if you do a "npm install" without parameters. If jspm could execute a script after each "jspm install x" (with parameters) we could automate the running of jspm-tsc-update. For example in package.json:

{
  "jspm": {
  "scripts": {
    "post-install-package": "jspm-tsc-update"
  }
}

However the first step would of course be to actually make the jspm-tsc-update tool :-).

[frederikschubert]

That sounds like a viable solution and I will be happy to contribute.
One difficulty that I see would be how the tool will decide whether the path mappings for the installed module should be added to the tsconfig.json or not.

+1 for a postinstall/postuninstall hook for jspm.

[jonaskello]

I think only packages that have embedded typings would have to be added to tsconfig. So maybe the tool could check package.json for a typings key in order to determine if it should be added to tsconfig.

Regarding the hook, maybe it is better if we had a hook for when map in config.js changes. I think that would cover both install and uninstall. Something like:

{
  "jspm": {
  "scripts": {
    "after-configjs-map-update": "jspm-tsc-update"
  }
}

[mikemichaelis]

Has this script hook been added to jspm?

[born2net]

I tried to setup TS@next latest with the following config:

{
  "compilerOptions": {
    "target": "ES5",
    "inlineSources": true,
    "module": "system",
    "moduleResolution": "node",
    "removeComments": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "noEmitHelpers": false,
    "sourceMap": true,
    "noResolve": false,
    "baseUrl": "./jspm_packages",
    "paths": {
      "@angular/*": [
        "npm/@angular/*"
      ],
      "rxjs/*": [
        "npm/rxjs@5.0.0-beta.6/*"
      ]
    }
  },
  "filesGlob": [
    "./**/*.ts",
    "!./node_modules",
    "/src/typings/app.d.ts"
  ],
  "exclude": [
    "src/public/world_data.ts",
    "temp",
    "node_modules",
    "node_modules/*",
    "jspm_packages",
    "typings",
    "dist",
    "typings/*",
    "typings/main.d.ts",
    "typings/main"
  ],
  "compileOnSave": false,
  "buildOnSave": true
}

but it seems to still use node_modules for module resolution, any thoughts on what to do different?

tx

Sean

[lookfirst]

Just a guess but moduleResolution: node?

On May 29, 2016, at 8:45 AM, JavaScriptNinja notifications@github.com wrote:

I tried to setup TS@next latest with the following config:

{
"compilerOptions": {
"target": "ES5",
"inlineSources": true,
"module": "system",
"moduleResolution": "node",
"removeComments": true,
"emitDecoratorMetadata": true,
"experimentalDecorators": true,
"noEmitHelpers": false,
"sourceMap": true,
"noResolve": false,
"baseUrl": "./jspm_packages",
"paths": {
"@angular/": [
"npm/@angular/"
],
"rxjs/": [
"npm/rxjs@5.0.0-beta.6/"
]
}
},
"filesGlob": [
"./*/.ts",
"!./node_modules",
"/src/typings/app.d.ts"
],
"exclude": [
"src/public/world_data.ts",
"temp",
"node_modules",
"node_modules/",
"jspm_packages",
"typings",
"dist",
"typings/",
"typings/main.d.ts",
"typings/main"
],
"compileOnSave": false,
"buildOnSave": true
}

but it seems to still use node_modules for module resolution, any thoughts on what to do different?

tx

Sean

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[born2net]

you got it @lookfirst I just changed it to classic

[born2net]

the good news is that when I switched to classics I get the errors but so far still am not able to get it to resolve properly.

current config is:

{
  "compilerOptions": {
    "target": "ES5",
    "inlineSources": true,
    "module": "system",
    "moduleResolution": "classic",
    "removeComments": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "noEmitHelpers": false,
    "sourceMap": true,
    "noResolve": false,
    "rootDir": "./",
    "baseUrl": ".",
    "paths": {
      "@angular/core": [
        "jspm_packages/npm/@angular/core@2.0.0-rc.1"
      ],
      "@angular/platform-browser-dynamic": [
        "jspm_packages/npm/@angular/platform-browser-dynamic@2.0.0-rc.1"
      ],
      "rxjs/*": [
        "jspm_packages/npm/rxjs@5.0.0-beta.6/*"
      ]
    }
  },
  "filesGlob": [
    "./**/*.ts",
    "!./node_modules",
    "/src/typings/app.d.ts"
  ],
  "exclude": [
    "src/public/world_data.ts",
    "temp",
    "node_modules",
    "node_modules/*",
    "jspm_packages",
    "typings",
    "dist",
    "typings/*",
    "typings/main.d.ts",
    "typings/main"
  ],
  "compileOnSave": false,
  "buildOnSave": true
}

[born2net]

here is a dump of: tsc --traceResolution
trying just to fix "@angular/core": at this point ( I can do the rest once that works)

======== Resolving module '@angular/core' from 'C:/msweb/studioDashboard/src/App.ts'. ========
'baseUrl' option is set to 'C:/msweb/studioDashboard/jspm_packages', using this value to resolve non-relative module name '@angular/core'
'paths' option is specified, looking for a pattern to match module name '@angular/core'.
Module name '@angular/core', matched pattern '@angular/core'.
Trying substitution 'npm/@angular/core@2.0.0-rc.1', candidate module location: 'npm/@angular/core@2.0.0-rc.1'.
File 'C:/msweb/studioDashboard/jspm_packages/npm/@angular/core@2.0.0-rc.1.ts' does not exist.
File 'C:/msweb/studioDashboard/jspm_packages/npm/@angular/core@2.0.0-rc.1.d.ts' does not exist.
File 'C:/msweb/studioDashboard/src/@angular/core.ts' does not exist.
File 'C:/msweb/studioDashboard/src/@angular/core.d.ts' does not exist.
File 'C:/msweb/studioDashboard/@angular/core.ts' does not exist.
File 'C:/msweb/studioDashboard/@angular/core.d.ts' does not exist.
File 'C:/msweb/@angular/core.ts' does not exist.
File 'C:/msweb/@angular/core.d.ts' does not exist.
File 'C:/@angular/core.ts' does not exist.
File 'C:/@angular/core.d.ts' does not exist.
======== Module name '@angular/core' was not resolved. ========

wondering why it's looking for .ts files? and not .js

[fabiandev]

@guybedford @jonaskello I've created a very basic package, actually named jspm-tsc-update, to add path mappings from installed jspm packages to tsconfig.json: https://github.com/fabiandev/jspm-tsc-update

[guybedford]

@fabiandev really nice work! We will need this for jspm 2 :)

[fabiandev]

@guybedford thanks! Currently it's a very simple approach and it can definitely be improved in terms of code quality and functionality (e.g. passing options). I just needed to get it working for a project of mine. I'll update the package eventually :)