An import path cannot end with a ".ts" extension. (TS 2.0.3)

[jlost]

Generating a new project with jspm init and specifying typescript as my transpiler, the convention for picking up typescript files is as follows:

packages: {
    "pets-gui": {
      "main": "main.js",
      "meta": {
        "*.ts": {
          "loader": "plugin-typescript"
        }
      }
    }
  }

My understanding is that this means everything with the .ts extension in the import is run through the typescript transpiler plugin.

However, Typescript 2.0.3 (called externally for intellisense) will report this as an error: An import path cannot end with a ".ts" extension. Consider importing './app.routing' instead, for instance. Of course, if I do that, the .ts files aren't transpiled by systemjs, and it just reports 404's as it tries to load "./app.routing" which doesn't exist.

Is there a work-around so I don't have to choose between SystemJS and my intellisense?

Apologies if this is the wrong place to raise this issue. Originally reported at jspm/jspm-cli#2103

0.17.0-beta.28
Running against local jspm install.

devConfig: {
    "map": {
      "plugin-typescript": "github:frankwallis/[email protected]"
    },
    "packages": {
      "github:frankwallis/[email protected]": {
        "map": {
          "typescript": "npm:[email protected]"
        }
      }
    }
  },

[frankwallis]

I think you need to add the defaultExtension: "ts" setting, see here for example

[aluanhaddad]

@jlost using jspm 0.17.0-beta.28 here and defaultExtension: "ts" on my package config works perfectly.

Here is what your config should look like.

packages: {
    "pets-gui": {
      "main": "main.ts", // or just "main"
      "defaultExtension" : "ts",
      "meta": {
        "*.ts": {
          "loader": "plugin-typescript"
        }
      }
    }
  }

Note that in the above you cannot use "main.js" it must be "main.ts" or simply "main".

The change in TypeScript behavior should not affect you. Importing files with an explicit .ts extension was never supposed to work and it doesn't need to. Even though it worked in the past it was a bad practice because it coupled your source to how it was transpiled.

[mavericken]

@aluanhaddad

The change in TypeScript behavior should not affect you. Importing files with an explicit .ts extension was never supposed to work and it doesn't need to. Even though it worked in the past it was a bad practice because it coupled your source to how it was transpiled.

Users of plugin-typescript are very much affected. Now we must have separate directories for TS, JS, TSX, and JSX files. So we get no benefits from the decoupling. If we ever needed to change the file extension, we will still have to change our import statements and the file name, but now we also have to change the directory.

Edit: @aluanhaddad enlightened me as to why extensions can't work. I still feel we need a way to handle multiple transpilation types in a single directory.

microsoft/TypeScript#11901

[aluanhaddad]

@mavericken I see the problem. You have multiple source extensions in the same directory and thus setting "defaultExtension": "ts" does not resolve the problem. Actually, in TypeScript 2.0, TypeScript will try to resolve a file with a .js extension to a .ts or .tsx file if not found. So perhaps using .js extensions for your imports would be more effective.

[mavericken]

@aluanhaddad Well, for TypeScript compiler itself, extension-less can already do the same thing, as it will also find the .ts or .tsx file. I feel that the role of plugin-typescript is to allow any valid typescript to be imported into SystemJS. Right now, this is not the case, as a valid typescript can contain both TS and TSX files in the same folder, but SystemJS + Plugin-Typescript cannot do that, so currently there exists valid typescript programs which Plugin-Typescript cannot support.

Edit: I have proposed a change to plugin-typescript that could handle it: #173
Edit again: I made a separate module to handle my concerns
https://www.npmjs.com/package/one-plugin