-
Notifications
You must be signed in to change notification settings - Fork 12k
ng test losing typings after retrigger #5332
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
Comments
After fiddling some more with this I notice that the typing error actually stops the rebuild, and runs the test again with the previous build. This make it look like the test succeeds even though the typing fails, but it's just showing a result from a previous build. To be able to run tests that actually tests my current code, I need to use |
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" ], ```
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
I'm sorry to say that it still doesn't work with the application I created for this issue. I updated to rc4 as shown here:
The change I see is that the test no longer succeeds, which is certainly an improvement. :) Am I doing something wrong by adding a d.ts file like this. |
@bialad it should be working now... can you show me your As part of the changes in that PR, we modified the default unit test tsconfig to actually include
We added it to https://github.com/angular/angular-cli/wiki/stories-1.0-update but I should have come back here to tell you that. If you do this change, does it work? |
@filipesilva The results are different now, but still not correct. Even though it's a standard cli application, I created a
This is very confusing to me, especially when the behavior isn't consistent. My guess is some sort of type caching not updating correctly... Hope you could follow my steps here, and am able to reproduce this issue. Otherwise it must be something in my platform. The fact the I can now run my tests without |
I'm experiencing a similar issue as well. I'm on cli, 1.0.0-rc.2 but our ng version is at 2.4.9. Karma is 1.5, typescript is 2.1.6. Running a test the first time works as expected, make a simple change to kick off another test run and the build will randomly fail with some random typescript error, such as 'HTMLInputElement' not found, for what appears to be a problem with the typings get lost. This doesn't appear to be an issue that occurs every time, seems to be a bit random. I've been noticing this off and on for about a week. Not sure the root cause, but the above sounds like a match. |
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?
Linux (Ubuntu 16.04)
Versions.
@angular/cli: 1.0.0-rc.1
node: 6.10.0
os: linux x64
@angular/common: 2.4.9
@angular/compiler: 2.4.9
@angular/core: 2.4.9
@angular/forms: 2.4.9
@angular/http: 2.4.9
@angular/platform-browser: 2.4.9
@angular/platform-browser-dynamic: 2.4.9
@angular/router: 3.4.9
@angular/cli: 1.0.0-rc.1
@angular/compiler-cli: 2.4.9
Repro steps.
The log given by the failure.
The text was updated successfully, but these errors were encountered: