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

ng test losing typings after retrigger #5332

Closed
bialad opened this issue Mar 9, 2017 · 7 comments · Fixed by #5504
Closed

ng test losing typings after retrigger #5332

bialad opened this issue Mar 9, 2017 · 7 comments · Fixed by #5504
Assignees

Comments

@bialad
Copy link

bialad commented Mar 9, 2017

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.

  • ng new ngTest
  • cd ngTest
  • yarn
  • Create folder typings in src
  • Create file common.d.ts in src/typings with content:
declare module Common {
  export interface IAction {
    type: string;
  }
}
  • In app.component.ts add a constructor
constructor() {
  const action: Common.IAction = { type: 'test' };
}
  • Running ng test once works
  • Saving app.component.ts (retriggering ng test) fails to find type definition, but test succeeds

The log given by the failure.

ERROR in /home/tobias/projects/external/ngTest/src/app/app.component.ts (12,19): Cannot find namespace 'Common'.)
Chrome 56.0.2924 (Linux 0.0.0): Executed 3 of 3 SUCCESS (0.222 secs / 0.215 secs)
@bialad
Copy link
Author

bialad commented Mar 9, 2017

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 ng test --single-run true.

@filipesilva filipesilva added this to the 1.0 Final Blocking milestone Mar 18, 2017
@filipesilva filipesilva self-assigned this Mar 18, 2017
filipesilva added a commit to filipesilva/angular-cli that referenced this issue Mar 18, 2017
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
filipesilva added a commit to filipesilva/angular-cli that referenced this issue Mar 18, 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:

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"
    ],
```
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 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
@bialad
Copy link
Author

bialad commented Mar 21, 2017

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:

    _                      _                 ____ _     ___
   / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
  / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
 / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
/_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
               |___/
@angular/cli: 1.0.0-rc.4
node: 6.10.0
os: linux x64
@angular/common: 2.4.10
@angular/compiler: 2.4.10
@angular/core: 2.4.10
@angular/forms: 2.4.10
@angular/http: 2.4.10
@angular/platform-browser: 2.4.10
@angular/platform-browser-dynamic: 2.4.10
@angular/router: 3.4.10
@angular/cli: 1.0.0-rc.4
@angular/compiler-cli: 2.4.10

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. ng serve and ng build works fine with this setup, just like before.

@filipesilva filipesilva reopened this Mar 24, 2017
@filipesilva
Copy link
Contributor

filipesilva commented Mar 24, 2017

@bialad it should be working now... can you show me your src/tsconfig.spec.json?

As part of the changes in that PR, we modified the default unit test tsconfig to actually include .d.ts files, which it didn't before.

  "include": [
    "**/*.spec.ts",
    "**/*.d.ts"
  ]

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?

@bialad
Copy link
Author

bialad commented Mar 25, 2017

@filipesilva The results are different now, but still not correct.

Even though it's a standard cli application, I created a repo to base the discussion on. I recreated the application from scratch with the CLI 1.0.0 and Anuglar 4.0.0 version, to be sure I'm not encountering any bugs because of mismatching version when updating.

  • Now when I run ng test the first time, everything work. As it did before.

  • Then changing the code in app.component.ts behaves as expected. For example changing 'test' to 1 fails. Great so far. :)

  • If I keep 'test' in AppComponent, and instead change the type property in common.d.ts from string to number, it successes. Not good.

  • If I keep the type change and stop and restart ng test it still succeeds, which it shouldn't...

  • Then changing 'test' i AppComponent to 1 succeeds (as it now should), BUT when changing 1 back to 'test' it falis (as it should).

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 single-run as long as I don't change my typings is i big step forward and a time saver.

@boldwade
Copy link

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.

@filipesilva
Copy link
Contributor

@bialad ah, that exist exists but it's a different one! #5634 seems to be related to interfaces and probably all .d.ts files instead. We're tracking it there instead.

@boldwade unfortunately to fix this you really need to update to 1.0.0, that's when the fix landed.

@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 6, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants