-
Notifications
You must be signed in to change notification settings - Fork 12k
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
tsconfig.app.json types are ignored #5351
Comments
Thank you so much, Its helped me a lot. |
this helped me, would be nice to know a official workaround is in place or if i need to just memorize this as a 'gotcha' fix |
There has to be something else going on here. I know for a fact that I also just tried the https://github.com/angular/angular-cli/wiki/stories-third-party-lib example and it worked. Have you tried clearing your local node_modules? Maybe there's something wrong in there. I can't reproduce this myself. If you can provide a repo where this happens I can investigate. |
Yeah this has persisted since rc1 after clearing nodemodules. Going to update the project to the latest RC Monday and will report back |
Actually, I was investigating #5332 and it seems they are related. The reason That error was seems to be masking this one. |
Blocked by angular#5500 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
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: The top level `files` and `include` options of `src/tsconfig.spec.json` should be removed. The `src/typings.d.ts` file should be modified to contain the following: ``` /* SystemJS module definition */ declare var module: NodeModule; interface NodeModule { id: string; } ``` Projects using TypeScript 2.0 or TypeScript 4.0 while NOT using tsconfig inheritance need to update the following files: - `src/tsconfig.app.json` - `src/tsconfig.spec.json` - `e2e/tsconfig.e2e.json` By adding the following entry to `compilerOptions`: ``` "typeRoots": [ "../node_modules/@types" ], ```
Further investigation reveals this is a windows specific problem. A fix is on the way. |
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
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
OS?
Windows 10 x64
Versions.
@angular/cli: 1.0.0-rc.1
node: 6.9.1
os: win32 x64
Repro steps.
Update package.json from
@angular/cli": "1.0.0-rc.0
to@angular/cli": "1.0.0-rc.1
.The log given by the failure.
Cannot find name 'require'
Cannot find namespace 'ol'
Cannot find name 'describe'
Cannot find name 'beforeEach'
Cannot find name 'it'
Cannot find name 'expect'
Mention any other details that might be useful.
When using certain 3rd party libraries or
require()
you need to add the types to thetsconfig.app.json
as described here https://github.com/angular/angular-cli/wiki/stories-third-party-lib. In the latest RC1 it looks like thetypes
option is ignored resulting the above error. If I remove thetypes
entry and replace it with the globaltypeRoots
entry it seems to work but is not ideal to pull in all types. This also affects thetsconfig.spec.json
.Breaks in RC1, used to work in RC0
Work around for RC1
The text was updated successfully, but these errors were encountered: