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

tsconfig.app.json types are ignored #5351

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

tsconfig.app.json types are ignored #5351

coryrylan opened this issue Mar 9, 2017 · 7 comments · Fixed by #5504
Labels
needs: repro steps We cannot reproduce the issue with the information given

Comments

@coryrylan
Copy link
Contributor

coryrylan commented Mar 9, 2017

Please provide us with the following information:

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 the tsconfig.app.json as described here https://github.com/angular/angular-cli/wiki/stories-third-party-lib. In the latest RC1 it looks like the types option is ignored resulting the above error. If I remove the types entry and replace it with the global typeRoots entry it seems to work but is not ideal to pull in all types. This also affects the tsconfig.spec.json.

Breaks in RC1, used to work in RC0

{
  "compilerOptions": {
    "sourceMap": true,
    "declaration": false,
    "moduleResolution": "node",
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "lib": [
      "es2016",
      "dom"
    ],
    "outDir": "../out-tsc/app",
    "target": "es5",
    "module": "es2015",
    "baseUrl": "",
    "types": [
      "node",
      "openlayers"
    ]
  },
  "exclude": [
    "test.ts",
    "**/*.spec.ts"
  ]
}

Work around for RC1

{
  "compilerOptions": {
    "sourceMap": true,
    "declaration": false,
    "moduleResolution": "node",
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "lib": [
      "es2016",
      "dom"
    ],
    "outDir": "../out-tsc/app",
    "target": "es5",
    "module": "es2015",
    "baseUrl": "",
    "typeRoots": [
      "../node_modules/@types"
    ]
  },
  "exclude": [
    "test.ts",
    "**/*.spec.ts"
  ]
}
@GustavoMantuan
Copy link

Thank you so much, Its helped me a lot.

@zurie
Copy link

zurie commented Mar 17, 2017

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

@filipesilva
Copy link
Contributor

There has to be something else going on here. I know for a fact that ng test worked in all RCs and it relies on having the jasmine types.

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.

@filipesilva filipesilva added the needs: repro steps We cannot reproduce the issue with the information given label Mar 17, 2017
@coryrylan
Copy link
Contributor Author

Yeah this has persisted since rc1 after clearing nodemodules. Going to update the project to the latest RC Monday and will report back

@filipesilva
Copy link
Contributor

Actually, I was investigating #5332 and it seems they are related.

The reason ng test works and has it's typings seems to be due to a weird (and erroneous) compilation setup.

That error was seems to be masking this one.

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
Copy link
Contributor

Further investigation reveals this is a windows specific problem. A fix is on the way.

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
@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.
Labels
needs: repro steps We cannot reproduce the issue with the information given
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants