-
-
Notifications
You must be signed in to change notification settings - Fork 538
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
Comments
Is this the same issue as the other Windows issues? See #216. |
@blakeembrey I'm not sure if it's the same. I agree that it seems similar, but in my case I also see this:
Which seems to indicate that the I also tried adding jasmine+types into the example and updating it, and it seems to not be specific to
|
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 |
I do, yes:
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. |
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
So I fired up the debugger and tried to figure out where that went wrong:
This seems to be because TypeScript expects the path separator to always be "/" and for I digged a bit more as to how the tsconfig path got generated, and it turns out it's in the TS I tried changing the result there manually to use This seemed to fix the
At this point I stopped. I get the feeling there's some kind of systematic issue with path handling on windows that |
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
@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 |
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; } ```
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; } ```
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; } ```
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
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
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
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
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
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
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
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
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
I have a simple repo at https://github.com/filipesilva/tsnode-typeroots that shows this issue.
To reproduce, do:
On a OSX machine, both npm scripts will complete successfully. On a Windows machine,
npm run tsnode
will fail compilation with the following error:This can be fixed either by:
typescript@2.0
"typeRoots": [ "node_modules/@types" ]
tocompilerOptions
intsconfig.json
I believe this is a bug because the
tsc
compilation itself completes successfully, whereas thetsnode
one does not.The text was updated successfully, but these errors were encountered: