Skip to content
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

Typeroots not inferred with TS2.1+ on Windows #283

Closed
filipesilva opened this issue Mar 6, 2017 · 7 comments
Closed

Typeroots not inferred with TS2.1+ on Windows #283

filipesilva opened this issue Mar 6, 2017 · 7 comments

Comments

@filipesilva
Copy link

I have a simple repo at https://github.com/filipesilva/tsnode-typeroots that shows this issue.

To reproduce, do:

git clone https://github.com/filipesilva/tsnode-typeroots
cd tsnode-typeroots
npm install
npm run tsc
npm run tsnode

On a OSX machine, both npm scripts will complete successfully. On a Windows machine, npm run tsnode will fail compilation with the following error:

TSError: ⨯ Unable to compile TypeScript
Cannot find type definition file for 'node'. (2688)
index.ts (1,13): Cannot find name 'module'. (2304)

This can be fixed either by:

  • installing typescript@2.0
  • adding "typeRoots": [ "node_modules/@types" ] to compilerOptions in tsconfig.json

I believe this is a bug because the tsc compilation itself completes successfully, whereas the tsnode one does not.

@blakeembrey
Copy link
Member

Is this the same issue as the other Windows issues? See #216.

@filipesilva
Copy link
Author

@blakeembrey I'm not sure if it's the same. I agree that it seems similar, but in my case I also see this:

Cannot find type definition file for 'node'. (2688)

Which seems to indicate that the node types are being looked for explicitly and not found.

I also tried adding jasmine+types into the example and updating it, and it seems to not be specific to node typings as the original poster in #216 hypothesized.

kamik@T460p MINGW64 /d/sandbox/tsnode-typeroots (master)
$ npm run tsc

> tsnode-typeroots@1.0.0 tsc D:\sandbox\tsnode-typeroots
> tsc -p ./tsconfig.json


kamik@T460p MINGW64 /d/sandbox/tsnode-typeroots (master)
$ npm run tsnode

> tsnode-typeroots@1.0.0 tsnode D:\sandbox\tsnode-typeroots
> ts-node -P ./tsconfig.json index.ts


D:\sandbox\tsnode-typeroots\node_modules\ts-node\src\index.ts:319
          throw new TSError(formatDiagnostics(diagnosticList, cwd, ts, lineOffset))
                ^
TSError: ⨯ Unable to compile TypeScript
Cannot find type definition file for 'jasmine'. (2688)
Cannot find type definition file for 'node'. (2688)
index.ts (1,13): Cannot find name 'module'. (2304)
index.ts (3,1): Cannot find name 'describe'. (2304)
index.ts (4,3): Cannot find name 'it'. (2304)
index.ts (5,5): Cannot find name 'expect'. (2304)
    at getOutput (D:\sandbox\tsnode-typeroots\node_modules\ts-node\src\index.ts:319:17)

@blakeembrey
Copy link
Member

I'm pretty sure it's the same issue, just a different situation. It seems to all be related to the paths, but no one on Windows has offered a PR (you could be the first!). Do you have an explicit types in tsconfig.json causing it to search for node and jasmine?

@filipesilva
Copy link
Author

I do, yes:

{
  "compilerOptions": {
    "types": [
      "node",
      "jasmine"
    ]
  },
  "files": [
    "index.ts"
  ]
}

In the original issue it's happening with TS@2.0, but in here it only happens on TS@2.1 and up. In fact, reverting to TS@2.0 actually fixes it.

@filipesilva
Copy link
Author

I tried doing some investigation by tracing directory checks (which is usually how stuff breaks on windows but not on linux/osx) and I think I'm on the right track.

I tried tracking cwd (index.tx#190) and failed directory lookups (index.ts#587):

cwd: D:\sandbox\tsnode-typeroots
dir doesn't exist: D:/node_modules/@types
dir doesn't exist: D:/node_modules
dir doesn't exist: D:/node_modules/@types
dir doesn't exist: D:/node_modules

So cwd is right but directory resolution seem to be broken somewhere, since it really shouldn't be looking for node_modules at my drive root.

I fired up the debugger and tried to figure out where that went wrong:
image

ts.getDirectoryPath is called with D:\sandbox\tsnode-typeroots\tsconfig.json but returns D: instead of D:\sandbox\tsnode-typeroots.

This seems to be because TypeScript expects the path separator to always be "/" and for getDirectories/directoryExists to correctly handle that.

I digged a bit more as to how the tsconfig path got generated, and it turns out it's in the TS loadSync function:
image

I tried changing the result there manually to use / separators, which also required getDirectories/directoryExists to always normalize paths.

This seemed to fix the Cannot find type definition file for 'x' errors, and node types were recognized, but the jasmine types still were not recognized:

kamik@T460p MINGW64 /D/sandbox/tsnode-typeroots (master)
$ node ./node_modules/ts-node/dist/_bin.js -P ./tsconfig.json index.ts
.

D:\sandbox\tsnode-typeroots\index.ts:3
describe('test', () => {
^
ReferenceError: describe is not defined
    at Object.<anonymous> (D:\sandbox\tsnode-typeroots\index.ts:3:1)

At this point I stopped. I get the feeling there's some kind of systematic issue with path handling on windows that tsc is doing but ts-node is not. If you have a hint as to how I should proceed from here, let me know.

filipesilva added a commit to angular/angular-cli that referenced this issue Mar 7, 2017
TS-Node with TypeScript 2.1+ does not infer `typeRoots`, so we need to list them explicitely in the root tsconfig.

Issue for TS-Node: TypeStrong/ts-node#283

Fix #5082
@blakeembrey
Copy link
Member

blakeembrey commented Mar 7, 2017

@filipesilva That is exactly the issue (see my comment in #284 (comment) too). The Jasmine issue you later ran into is actually because TypeScript compilation passed but at runtime the describe keyword did not exist - so it looks like whatever you tweaked was correct. In terms of where the fix is, TypeScript exports a normalizeSlashes utility they use in places and we can use that on whichever location is needed (tsconfig isn't a TypeScript utility, but a library that was needed to get around a similar paths issue when resolving the tsconfig.json file consistently).

@filipesilva
Copy link
Author

I was just getting ready to push a PR when I noticed #245 - it's exactly what I was doing plus a few more fixes. Cheers @Jontem!

filipesilva added a commit to filipesilva/angular-cli that referenced this issue Mar 19, 2017
Blocked by angular#5500 (fix is included in this PR so that CI will run).

Our unit test webpack config was erroneously sending in entry points to karma-webpack, who should receive no entry points.

This in turn was hiding errors related to typeRoots lookups.

It was also causing unit tests compilation to behave weirdly: unit test errors would not stop compilation, because other entries would still compile.

This might also have contributed to the overall slowness of unit tests in angular#5423.

Fix angular#5332
Fix angular#5351

BREAKING CHANGE:

Related to TypeStrong/ts-node#283

The `src/typings.d.ts` file should be modified to contain the following:
```
/* SystemJS module definition */
declare var module: NodeModule;
interface NodeModule {
  id: string;
}
```
filipesilva added a commit to filipesilva/angular-cli that referenced this issue Mar 19, 2017
Blocked by angular#5500 (fix is included in this PR so that CI will run).

Our unit test webpack config was erroneously sending in entry points to karma-webpack, who should receive no entry points.

This in turn was hiding errors related to typeRoots lookups.

It was also causing unit tests compilation to behave weirdly: unit test errors would not stop compilation, because other entries would still compile.

This might also have contributed to the overall slowness of unit tests in angular#5423.

Related to TypeStrong/ts-node#283
Fix angular#5332
Fix angular#5351

BREAKING CHANGE:

The following files need changes:

- `src/tsconfig.spec.json`: remove `files` and `include` entries. Add `"dom"` to the `lib` array.

- `src/typings.d.ts`: replace
```
declare var module: {
  id: string
}
```
with
```
declare var module: NodeModule;
interface NodeModule {
  id: string;
}
```
filipesilva added a commit to filipesilva/angular-cli that referenced this issue Mar 19, 2017
Blocked by angular#5500 (fix is included in this PR so that CI will run).

Our unit test webpack config was erroneously sending in entry points to karma-webpack, who should receive no entry points.

This in turn was hiding errors related to typeRoots lookups.

It was also causing unit tests compilation to behave weirdly: unit test errors would not stop compilation, because other entries would still compile.

This might also have contributed to the overall slowness of unit tests in angular#5423.

Related to TypeStrong/ts-node#283
Fix angular#5332
Fix angular#5351

BREAKING CHANGE:

The following files need changes:

- `src/tsconfig.spec.json`: remove `files` and `include` entries. Add `"dom"` to the `lib` array if not using tsconfig inheritance.

- `src/typings.d.ts`: replace
```
declare var module: {
  id: string
}
```
with
```
declare var module: NodeModule;
interface NodeModule {
  id: string;
}
```
filipesilva added a commit to filipesilva/angular-cli that referenced this issue Mar 19, 2017
Blocked by angular#5500 (fix is included in this PR so that CI will run).

Our unit test webpack config was erroneously sending in entry points to karma-webpack, who should receive no entry points.

This in turn was hiding errors related to typeRoots lookups.

It was also causing unit tests compilation to behave weirdly: unit test errors would not stop compilation, because other entries would still compile.

This might also have contributed to the overall slowness of unit tests in angular#5423.

Related to TypeStrong/ts-node#283
Fix angular#5332
Fix angular#5351
filipesilva added a commit to filipesilva/angular-cli that referenced this issue Mar 19, 2017
Blocked by angular#5500 (fix is included in this PR so that CI will run).

Our unit test webpack config was erroneously sending in entry points to karma-webpack, who should receive no entry points.

This in turn was hiding errors related to typeRoots lookups.

It was also causing unit tests compilation to behave weirdly: unit test errors would not stop compilation, because other entries would still compile.

This might also have contributed to the overall slowness of unit tests in angular#5423.

Related to TypeStrong/ts-node#283
Fix angular#5332
Fix angular#5351
filipesilva added a commit to filipesilva/angular-cli that referenced this issue Mar 19, 2017
Blocked by angular#5500 (fix is included in this PR so that CI will run).

Our unit test webpack config was erroneously sending in entry points to karma-webpack, who should receive no entry points.

This in turn was hiding errors related to typeRoots lookups.

It was also causing unit tests compilation to behave weirdly: unit test errors would not stop compilation, because other entries would still compile.

This might also have contributed to the overall slowness of unit tests in angular#5423.

Related to TypeStrong/ts-node#283
Fix angular#5332
Fix angular#5351
filipesilva added a commit to filipesilva/angular-cli that referenced this issue Mar 19, 2017
Blocked by angular#5500 (fix is included in this PR so that CI will run).

Our unit test webpack config was erroneously sending in entry points to karma-webpack, who should receive no entry points.

This in turn was hiding errors related to typeRoots lookups.

It was also causing unit tests compilation to behave weirdly: unit test errors would not stop compilation, because other entries would still compile.

This might also have contributed to the overall slowness of unit tests in angular#5423.

Related to TypeStrong/ts-node#283
Fix angular#5332
Fix angular#5351
filipesilva added a commit to filipesilva/angular-cli that referenced this issue Mar 19, 2017
Blocked by angular#5500 (fix is included in this PR so that CI will run).

Our unit test webpack config was erroneously sending in entry points to karma-webpack, who should receive no entry points.

This in turn was hiding errors related to typeRoots lookups.

It was also causing unit tests compilation to behave weirdly: unit test errors would not stop compilation, because other entries would still compile.

This might also have contributed to the overall slowness of unit tests in angular#5423.

Related to TypeStrong/ts-node#283
Fix angular#5332
Fix angular#5351
filipesilva added a commit to filipesilva/angular-cli that referenced this issue Mar 19, 2017
Blocked by angular#5500 (fix is included in this PR so that CI will run).

Our unit test webpack config was erroneously sending in entry points to karma-webpack, who should receive no entry points.

This in turn was hiding errors related to typeRoots lookups.

It was also causing unit tests compilation to behave weirdly: unit test errors would not stop compilation, because other entries would still compile.

This might also have contributed to the overall slowness of unit tests in angular#5423.

Related to TypeStrong/ts-node#283

Fix angular#3911
Fix angular#5332
Fix angular#5351
filipesilva added a commit to filipesilva/angular-cli that referenced this issue Mar 20, 2017
Blocked by angular#5500 (fix is included in this PR so that CI will run).

Our unit test webpack config was erroneously sending in entry points to karma-webpack, who should receive no entry points.

This in turn was hiding errors related to typeRoots lookups.

It was also causing unit tests compilation to behave weirdly: unit test errors would not stop compilation, because other entries would still compile.

This might also have contributed to the overall slowness of unit tests in angular#5423.

Related to TypeStrong/ts-node#283

Fix angular#3911
Fix angular#5332
Fix angular#5351
hansl pushed a commit to angular/angular-cli that referenced this issue Mar 20, 2017
Blocked by #5500 (fix is included in this PR so that CI will run).

Our unit test webpack config was erroneously sending in entry points to karma-webpack, who should receive no entry points.

This in turn was hiding errors related to typeRoots lookups.

It was also causing unit tests compilation to behave weirdly: unit test errors would not stop compilation, because other entries would still compile.

This might also have contributed to the overall slowness of unit tests in #5423.

Related to TypeStrong/ts-node#283

Fix #3911
Fix #5332
Fix #5351
asnowwolf pushed a commit to asnowwolf/angular-cli that referenced this issue Apr 12, 2017
TS-Node with TypeScript 2.1+ does not infer `typeRoots`, so we need to list them explicitely in the root tsconfig.

Issue for TS-Node: TypeStrong/ts-node#283

Fix angular#5082
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants