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

Angular 5: NPM Link - model/index.ts is not part of the compilation. #8284

Open
thaoula opened this Issue Nov 2, 2017 · 84 comments

Comments

Projects
None yet
@thaoula

thaoula commented Nov 2, 2017

Bug Report or Feature Request (mark with an x)

- [x] bug report -> please search issues before submitting
- [ ] feature request

Versions.

Angular CLI: 1.5.0
Node: 8.7.0
OS: darwin x64
Angular: 5.0.0

Repro steps.

We have a the following folder structure in a git mono-repo

/api (Express Node App)
/model (NPM package using NPM Link, contains mostly typescript interfaces)
/web (Angular)

When using Angular 4.46 and Angular CLI 1.5.rc2 and we were able to make reference to the interfaces defined in the model folder using npm link and using the following example
import { entity } @app/model

We use ng serve to start the app.

After upgrading Angular to V5 and Angular CLI to 1.5.0 we now get the following error -

The log given by the failure.

Module build failed: Error: /Users/thaoula/Projects/platform/model/index.ts is not part of the compilation. Please make sure it is in your tsconfig via the 'files' or 'include' property.

The occurs for JIT and AOT builds.
Running TSC does not result in in errors.

Desired functionality.

Would like be able to build the app using Angular 5

Thanks,
Tarek

@rolaveric

This comment has been minimized.

Show comment
Hide comment
@rolaveric

rolaveric Nov 2, 2017

I can report a similar issue.
Key differences:

  1. I'm not using npm link, I've just installed another git repo via npm with typescript source (ie. original .ts files).
  2. The error I'm getting is: node_modules/other-repo/src/lib/index.ts is not part of the compilation output. Please check the other error messages for details.

Was previously working fine with Angular 4.4.6 and Angular CLI 1.4.7

I'll try to create a minimal repo to reproduce the issue once I get home.

rolaveric commented Nov 2, 2017

I can report a similar issue.
Key differences:

  1. I'm not using npm link, I've just installed another git repo via npm with typescript source (ie. original .ts files).
  2. The error I'm getting is: node_modules/other-repo/src/lib/index.ts is not part of the compilation output. Please check the other error messages for details.

Was previously working fine with Angular 4.4.6 and Angular CLI 1.4.7

I'll try to create a minimal repo to reproduce the issue once I get home.

@suresh2018

This comment has been minimized.

Show comment
Hide comment
@suresh2018

suresh2018 Nov 2, 2017

yes i m also faced this issue .
angular 5 rc 9 and clic 1.5.0

suresh2018 commented Nov 2, 2017

yes i m also faced this issue .
angular 5 rc 9 and clic 1.5.0

@xiongyayun428

This comment has been minimized.

Show comment
Hide comment
@xiongyayun428

xiongyayun428 commented Nov 2, 2017

me too

@ChristianSchroedel

This comment has been minimized.

Show comment
Hide comment
@ChristianSchroedel

ChristianSchroedel Nov 2, 2017

Same here - without npm link, but with dependencies on typescript libraries in other git repositories

ChristianSchroedel commented Nov 2, 2017

Same here - without npm link, but with dependencies on typescript libraries in other git repositories

@diagramatics

This comment has been minimized.

Show comment
Hide comment
@diagramatics

diagramatics Nov 2, 2017

Contributor

I've been testing with several version combinations to flush this out and it seems like it's the CLI causing it. I'm running v1.5.0 with Angular on v5.0.0 final and a similar error shows. Rolling the CLI back to rc8 fixes it.

Then I reverted 9b43a9c manually and the error subsides.

Contributor

diagramatics commented Nov 2, 2017

I've been testing with several version combinations to flush this out and it seems like it's the CLI causing it. I'm running v1.5.0 with Angular on v5.0.0 final and a similar error shows. Rolling the CLI back to rc8 fixes it.

Then I reverted 9b43a9c manually and the error subsides.

@rolaveric

This comment has been minimized.

Show comment
Hide comment
@rolaveric

rolaveric Nov 2, 2017

I've found that I only get the problem with ng serve - not with ng build.
Specifically: ng build --aot --prod --sourcemaps --stats-json --delete-output-path=false --progress=false

rolaveric commented Nov 2, 2017

I've found that I only get the problem with ng serve - not with ng build.
Specifically: ng build --aot --prod --sourcemaps --stats-json --delete-output-path=false --progress=false

@rolaveric

This comment has been minimized.

Show comment
Hide comment
@rolaveric

rolaveric Nov 2, 2017

I can confirm what @diagramatics said about rolling back to rc8 working, but I didn't get the same joy from reverting 9b43a9c
I also noticed that I get the same error when running ng test (ie. X is not part of the compilation output.) - even with rc8.

rolaveric commented Nov 2, 2017

I can confirm what @diagramatics said about rolling back to rc8 working, but I didn't get the same joy from reverting 9b43a9c
I also noticed that I get the same error when running ng test (ie. X is not part of the compilation output.) - even with rc8.

@filipesilva

This comment has been minimized.

Show comment
Hide comment
@filipesilva

filipesilva Nov 2, 2017

Member

Hey all, this is a side effect of the stricter tsconfig as described in https://blog.angular.io/version-5-0-0-of-angular-now-available-37e414935ced#148d.

The tsconfig file is what determines what TS files are compiled. The error you are getting means that the files mentioned are NOT being compiled.

Before we used to compile all files, essentially ignoring what tsconfig listed. This was a bug, because if you don't include a file in the compilation then it should not be compiled.

By default ./src/tsconfig.app.json will only pick up files inside src/. If you have a file outside source, it won't be picked up. But you can add more files to the tsconfig via either files or include.

So for @thaoula's case, you probably want to add this the files in ../models to your tsconfig.app.json and also to your tsconfig.spec.json:

{
  "extends": "../tsconfig.json",
  "compilerOptions": {
    // ...
  },
  "include": [
    "../models/**/*.ts"
  ],
  "exclude": [
    // ...
  ],
}

You can read more about tsconfig files in https://github.com/Microsoft/TypeScript-Handbook/blob/master/pages/tsconfig.json.md.

@rolaveric's case is slightly different. You have TS files in your node_modules. This really goes against how libraries should be packaged: libraries should never ship their source .ts files.

The reason for this rule is that the TypeScript version your app isn't necessarily the same as the TS version your library uses. Different versions of TS can produce different output, and give different errors for the same input. They don't even support the same language features. So packaging libraries with TS sources will always break someone's project.

So we don't really support using incorrectly packaged libraries with TS sources. It's something you do at your risk.

That being said, maybe you can try adding it to the include array. But I can't guarantee that will work in the future because it's still an incorrectly packaged library.

Regarding AOT: as far as I can tell, AOT is still incorrectly compiling TS that is not included in the tsconfig. I'll bring this up with the compiler team. (Edit: reported as angular/angular#20115)

Member

filipesilva commented Nov 2, 2017

Hey all, this is a side effect of the stricter tsconfig as described in https://blog.angular.io/version-5-0-0-of-angular-now-available-37e414935ced#148d.

The tsconfig file is what determines what TS files are compiled. The error you are getting means that the files mentioned are NOT being compiled.

Before we used to compile all files, essentially ignoring what tsconfig listed. This was a bug, because if you don't include a file in the compilation then it should not be compiled.

By default ./src/tsconfig.app.json will only pick up files inside src/. If you have a file outside source, it won't be picked up. But you can add more files to the tsconfig via either files or include.

So for @thaoula's case, you probably want to add this the files in ../models to your tsconfig.app.json and also to your tsconfig.spec.json:

{
  "extends": "../tsconfig.json",
  "compilerOptions": {
    // ...
  },
  "include": [
    "../models/**/*.ts"
  ],
  "exclude": [
    // ...
  ],
}

You can read more about tsconfig files in https://github.com/Microsoft/TypeScript-Handbook/blob/master/pages/tsconfig.json.md.

@rolaveric's case is slightly different. You have TS files in your node_modules. This really goes against how libraries should be packaged: libraries should never ship their source .ts files.

The reason for this rule is that the TypeScript version your app isn't necessarily the same as the TS version your library uses. Different versions of TS can produce different output, and give different errors for the same input. They don't even support the same language features. So packaging libraries with TS sources will always break someone's project.

So we don't really support using incorrectly packaged libraries with TS sources. It's something you do at your risk.

That being said, maybe you can try adding it to the include array. But I can't guarantee that will work in the future because it's still an incorrectly packaged library.

Regarding AOT: as far as I can tell, AOT is still incorrectly compiling TS that is not included in the tsconfig. I'll bring this up with the compiler team. (Edit: reported as angular/angular#20115)

@MakesNine

This comment has been minimized.

Show comment
Hide comment
@MakesNine

MakesNine Nov 2, 2017

We have the same problem described by @thaoula , but for a file that is located inside the normal tree structure created by the angular-cli. The error occurs with angular 5.0.0 final and angular-cli 1.5. We can "ng serve" the app with angular 5.0.0 and angular-cli 1.4.4.

The file that is not part of the compilation in our project is located at:
src/app/core/stateManagement/Models/genericCourse.ts

We never included or excluded files using tsconfig.json so it doesn't seem that the problem comes from the stricker tsconfig usage describeb above. To make sure, I created an empty project using angular-cli 1.5.0 and replaced the tsconfig.json and tsconfig.app.json files in our project with the ones created by the new cli and it didn't solve the problem.

Another thing we have in commun with @thaoula is that the file that is not included in the compilation only contains interface and class definitions. So there might be something with that.

MakesNine commented Nov 2, 2017

We have the same problem described by @thaoula , but for a file that is located inside the normal tree structure created by the angular-cli. The error occurs with angular 5.0.0 final and angular-cli 1.5. We can "ng serve" the app with angular 5.0.0 and angular-cli 1.4.4.

The file that is not part of the compilation in our project is located at:
src/app/core/stateManagement/Models/genericCourse.ts

We never included or excluded files using tsconfig.json so it doesn't seem that the problem comes from the stricker tsconfig usage describeb above. To make sure, I created an empty project using angular-cli 1.5.0 and replaced the tsconfig.json and tsconfig.app.json files in our project with the ones created by the new cli and it didn't solve the problem.

Another thing we have in commun with @thaoula is that the file that is not included in the compilation only contains interface and class definitions. So there might be something with that.

@filipesilva

This comment has been minimized.

Show comment
Hide comment
@filipesilva

filipesilva Nov 2, 2017

Member

@MakesNine that sounds like a different issue altogether, and one that we thought was fixed. Could you give me a repro of that please?

Member

filipesilva commented Nov 2, 2017

@MakesNine that sounds like a different issue altogether, and one that we thought was fixed. Could you give me a repro of that please?

@KevinFernandes

This comment has been minimized.

Show comment
Hide comment
@KevinFernandes

KevinFernandes Nov 2, 2017

We are having a similar issue, as well, after upgrading. It is complaining about all of our library packages under node_modules with this same exact error (all packages are installed with NPM so no links). Are we going to have to "include" each package separately in the tsconfig file? This would be a nightmare if its true, now and for maintenance in the future. Is there another solution or something else we can do first before using this new version which obviously breaks us completely?

KevinFernandes commented Nov 2, 2017

We are having a similar issue, as well, after upgrading. It is complaining about all of our library packages under node_modules with this same exact error (all packages are installed with NPM so no links). Are we going to have to "include" each package separately in the tsconfig file? This would be a nightmare if its true, now and for maintenance in the future. Is there another solution or something else we can do first before using this new version which obviously breaks us completely?

@MakesNine

This comment has been minimized.

Show comment
Hide comment
@MakesNine

MakesNine Nov 2, 2017

@filipesilva I have been trying to reproduce the problem in a small project, but I haven't succeded so far. I will keep trying to isolate the problem to find the source of it.

Here's the exact error I'm getting:

ERROR in ./src/app/core/StateManagement/models/genericCourse.models.ts
Module build failed: Error: D:\Projects\LtiisWeb\src\app\core\StateManagement\models\genericCourse.models.ts is not part o
f the compilation. Please make sure it is in your tsconfig via the 'files' or 'include' property.
at AngularCompilerPlugin.getCompiledFile (D:\Projects\LtiisWeb\node_modules@ngtools\webpack\src\angular_compiler_plug
in.js:624:23)
at plugin.done.then (D:\Projects\LtiisWeb\node_modules@ngtools\webpack\src\loader.js:467:39)
@ ./src/app/+generic-courses/generic-course.component.ts 23:0-84
@ ./src/app/+generic-courses/generic-courses.module.ts
@ ./src/$$_lazy_route_resource lazy
@ ./node_modules/@angular/core/esm5/core.js
@ ./src/main.ts
@ multi webpack-dev-server/client?http://0.0.0.0:0 ./src/main.ts

MakesNine commented Nov 2, 2017

@filipesilva I have been trying to reproduce the problem in a small project, but I haven't succeded so far. I will keep trying to isolate the problem to find the source of it.

Here's the exact error I'm getting:

ERROR in ./src/app/core/StateManagement/models/genericCourse.models.ts
Module build failed: Error: D:\Projects\LtiisWeb\src\app\core\StateManagement\models\genericCourse.models.ts is not part o
f the compilation. Please make sure it is in your tsconfig via the 'files' or 'include' property.
at AngularCompilerPlugin.getCompiledFile (D:\Projects\LtiisWeb\node_modules@ngtools\webpack\src\angular_compiler_plug
in.js:624:23)
at plugin.done.then (D:\Projects\LtiisWeb\node_modules@ngtools\webpack\src\loader.js:467:39)
@ ./src/app/+generic-courses/generic-course.component.ts 23:0-84
@ ./src/app/+generic-courses/generic-courses.module.ts
@ ./src/$$_lazy_route_resource lazy
@ ./node_modules/@angular/core/esm5/core.js
@ ./src/main.ts
@ multi webpack-dev-server/client?http://0.0.0.0:0 ./src/main.ts

@filipesilva

This comment has been minimized.

Show comment
Hide comment
@filipesilva

filipesilva Nov 2, 2017

Member

@MakesNine so if you try having a file with just interfaces it's still fine in a new project? Hm... I've heard of problems with casing. Are your imports perhaps using the wrong casing? Does it still happen if you add a non-interface export to that file? That seems to be a lazy route, perhaps it's related. Can you try making that route not lazy?

@KevinFernandes this definitely shouldn't happen to all library packages, unless somehow you're just using packages that weren't packaged well. Can you give me examples of a couple of these packages? I can have a look.

Member

filipesilva commented Nov 2, 2017

@MakesNine so if you try having a file with just interfaces it's still fine in a new project? Hm... I've heard of problems with casing. Are your imports perhaps using the wrong casing? Does it still happen if you add a non-interface export to that file? That seems to be a lazy route, perhaps it's related. Can you try making that route not lazy?

@KevinFernandes this definitely shouldn't happen to all library packages, unless somehow you're just using packages that weren't packaged well. Can you give me examples of a couple of these packages? I can have a look.

@MakesNine

This comment has been minimized.

Show comment
Hide comment
@MakesNine

MakesNine Nov 2, 2017

@filipesilva yest, I can build a new project and import a file with only interfaces from a lazy loaded module. I will double check the casing and try the original app with a non lazy route for the module where the error originates.

MakesNine commented Nov 2, 2017

@filipesilva yest, I can build a new project and import a file with only interfaces from a lazy loaded module. I will double check the casing and try the original app with a non lazy route for the module where the error originates.

@MakesNine

This comment has been minimized.

Show comment
Hide comment
@MakesNine

MakesNine Nov 2, 2017

@filipesilva I have added an import and exported a function from the file refusing to be part of the compilation and it didn't help.
I have changed all the routes, in app-routing.module.ts, that have components importing type definitions from that file so that they wouldn't be lazy loaded and the app compiled, but didn't work. I had forgotten to import the modules, in app.module.ts', that contained the components now used in the non lazy loaded routes. Once I add the required imports in app.module.ts, I get the same problem that I get with lazy loaded routes. I have also checked casing and all seems ok on that front.

MakesNine commented Nov 2, 2017

@filipesilva I have added an import and exported a function from the file refusing to be part of the compilation and it didn't help.
I have changed all the routes, in app-routing.module.ts, that have components importing type definitions from that file so that they wouldn't be lazy loaded and the app compiled, but didn't work. I had forgotten to import the modules, in app.module.ts', that contained the components now used in the non lazy loaded routes. Once I add the required imports in app.module.ts, I get the same problem that I get with lazy loaded routes. I have also checked casing and all seems ok on that front.

@rolaveric

This comment has been minimized.

Show comment
Hide comment
@rolaveric

rolaveric Nov 2, 2017

Thanks @filipesilva - that explains my issue.
I tried explicitly including my internal libraries using include, but that's giving me other grief (picking up on test suites, despite using exclude). So I'll do it properly and have them expose compiled code.
I knew it was something I should do, but with them only being used internally by the company, I let it slide.

Thanks again to you and all the contributors for your hard work on Angular CLI - it's an excellent tool and very much appreciated.

rolaveric commented Nov 2, 2017

Thanks @filipesilva - that explains my issue.
I tried explicitly including my internal libraries using include, but that's giving me other grief (picking up on test suites, despite using exclude). So I'll do it properly and have them expose compiled code.
I knew it was something I should do, but with them only being used internally by the company, I let it slide.

Thanks again to you and all the contributors for your hard work on Angular CLI - it's an excellent tool and very much appreciated.

@stuartkuentzel

This comment has been minimized.

Show comment
Hide comment
@stuartkuentzel

stuartkuentzel Nov 3, 2017

I was having the same issue after updating. Like some other people, the ts files were all part of the standard CLI structure tree. Turned out it was a case sensitivity issue for me. I had accidentally written something like...

import { Comment } from './Comment' while in other components import { Comment } from './comment'. Running a normal build would throw me a helpful warning before erroring out, but building for prod only showed me the "Please make sure it is in your tsconfig via the 'files' or 'include' property" error. Fixed the casing issue and prod builds for me fine.

stuartkuentzel commented Nov 3, 2017

I was having the same issue after updating. Like some other people, the ts files were all part of the standard CLI structure tree. Turned out it was a case sensitivity issue for me. I had accidentally written something like...

import { Comment } from './Comment' while in other components import { Comment } from './comment'. Running a normal build would throw me a helpful warning before erroring out, but building for prod only showed me the "Please make sure it is in your tsconfig via the 'files' or 'include' property" error. Fixed the casing issue and prod builds for me fine.

@MakesNine

This comment has been minimized.

Show comment
Hide comment
@MakesNine

MakesNine Nov 3, 2017

I finally got my app to compile. It turned out that it was a casing issue indeed.
The error I was getting was:
ERROR in ./src/app/core/StateManagement/models/genericCourse.models.ts

And the solution is to change the related import to:
./src/app/core/stateManagement/models/genericCourse.models.ts

Curiously, I have other files in that folder that were also imported with StateMangement in the path and the compiler didn't complain.

Thansk for your input @filipesilva

MakesNine commented Nov 3, 2017

I finally got my app to compile. It turned out that it was a casing issue indeed.
The error I was getting was:
ERROR in ./src/app/core/StateManagement/models/genericCourse.models.ts

And the solution is to change the related import to:
./src/app/core/stateManagement/models/genericCourse.models.ts

Curiously, I have other files in that folder that were also imported with StateMangement in the path and the compiler didn't complain.

Thansk for your input @filipesilva

@prasadkadiyala

This comment has been minimized.

Show comment
Hide comment
@prasadkadiyala

prasadkadiyala Nov 3, 2017

We got the same problem when importing the modules.

prasadkadiyala commented Nov 3, 2017

We got the same problem when importing the modules.

cburgdorf added a commit to machinelabs/machinelabs that referenced this issue Nov 3, 2017

chore(client): distribute shared libs in JS via dist
Previously our shared libs did not have a dedicated
dist folder where the compiled JS would go.

This setup introduces problems down the road and
is discouraged.

See:
angular/angular-cli#8284 (comment)

This change migrates all shared libs to the new
layout.
@filipesilva

This comment has been minimized.

Show comment
Hide comment
@filipesilva

filipesilva Nov 3, 2017

Member

@MakesNine that is weird indeed, and I'm not really sure why that happens... I expected all bad paths to throw an error somehow. Will keep an eye out for more such casing reports.

Member

filipesilva commented Nov 3, 2017

@MakesNine that is weird indeed, and I'm not really sure why that happens... I expected all bad paths to throw an error somehow. Will keep an eye out for more such casing reports.

@KevinFernandes

This comment has been minimized.

Show comment
Hide comment
@KevinFernandes

KevinFernandes Nov 3, 2017

@filipesilva I see hundreds of errors so its hard to sort through them. From what I can see at the moment it's all of "my" library packages, packages that we build and publish to a local repository. We package all of the .ts files as well as a webpacked bundle file.

When we were building with SystemJS it made sense that we had to explicitly specify all of the bundles to include from node_modules, but with the CLI it seemed to just work without any extra specifications. It made our lives a thousand times easier. But now it seems what we thought was a feature was actually a bug in CLI and possibly something that we are doing wrong (and have been for more than a year now).

So what exactly is the problem? Is it that the CLI was compiling the .ts files that we had in our library packages and so did not need the bundles? If that is the case then how do we now tell the CLI to use the bundle? Is it something to do differently when packaging the library bundles or is it some angular-cli.json configuration we have to change.

Sorry, up until now we had though we had finally figured out this JavaScript eco system, but now it seems we still have some things to learn.

KevinFernandes commented Nov 3, 2017

@filipesilva I see hundreds of errors so its hard to sort through them. From what I can see at the moment it's all of "my" library packages, packages that we build and publish to a local repository. We package all of the .ts files as well as a webpacked bundle file.

When we were building with SystemJS it made sense that we had to explicitly specify all of the bundles to include from node_modules, but with the CLI it seemed to just work without any extra specifications. It made our lives a thousand times easier. But now it seems what we thought was a feature was actually a bug in CLI and possibly something that we are doing wrong (and have been for more than a year now).

So what exactly is the problem? Is it that the CLI was compiling the .ts files that we had in our library packages and so did not need the bundles? If that is the case then how do we now tell the CLI to use the bundle? Is it something to do differently when packaging the library bundles or is it some angular-cli.json configuration we have to change.

Sorry, up until now we had though we had finally figured out this JavaScript eco system, but now it seems we still have some things to learn.

@filipesilva

This comment has been minimized.

Show comment
Hide comment
@filipesilva

filipesilva Nov 3, 2017

Member

@KevinFernandes ok so that it happens on your local libs makes sense considering the other reports in this issue. Yes, before it seems like the CLI was compiling the TS in your local libraries, which was just a ticking time bomb really.

The way to address this in your codebase really depends on how you build your libs... Do you use an existing library to do it? I think a lot of users use https://github.com/dherges/ng-packagr and seem to be happy with it. I haven't myself though.

Member

filipesilva commented Nov 3, 2017

@KevinFernandes ok so that it happens on your local libs makes sense considering the other reports in this issue. Yes, before it seems like the CLI was compiling the TS in your local libraries, which was just a ticking time bomb really.

The way to address this in your codebase really depends on how you build your libs... Do you use an existing library to do it? I think a lot of users use https://github.com/dherges/ng-packagr and seem to be happy with it. I haven't myself though.

cburgdorf added a commit to machinelabs/machinelabs that referenced this issue Nov 3, 2017

chore(client): distribute shared libs in JS via dist
Previously our shared libs did not have a dedicated
dist folder where the compiled JS would go.

This setup introduces problems down the road and
is discouraged.

See:
angular/angular-cli#8284 (comment)

This change migrates all shared libs to the new
layout.

cburgdorf added a commit to machinelabs/machinelabs that referenced this issue Nov 4, 2017

chore(client): distribute shared libs in JS via dist
Previously our shared libs did not have a dedicated
dist folder where the compiled JS would go.

This setup introduces problems down the road and
is discouraged.

See:
angular/angular-cli#8284 (comment)

This change migrates all shared libs to the new
layout.

This change has several implications:

1. There is a new special `build.js` in `./shared` that builds
all shared libs in the right order. There's an alias admin-cli
taks for this but the script itself needs to live outside the
admin-cli because the admin-cli itself depends on the shared libs,
hence *building* the shared libs can not depend on the admin-cli.

2. Building the shared libs is currently quite costly. Triggering
implicitly was slowing down the build and general feedback loop
for the development. Therefore the shared libs now need to be build
explicitly. This can be done either by running `build.js` in `./shared`
or running the `build-shared` command of the admin-cli.

Notice that building the shared libs does not automatically update
the libs in client and server. For the client there is an npm script
called `updated-shared` that can be run to update the libs. However, the
server does trigger a build for the shared libs and also updated the
packages. However, since this slows down the build quite a bit this
can be skipped by passing --skip-shared` when building the server.

cburgdorf added a commit to machinelabs/machinelabs that referenced this issue Nov 4, 2017

chore(client): distribute shared libs in JS via dist
Previously our shared libs did not have a dedicated
dist folder where the compiled JS would go.

This setup introduces problems down the road and
is discouraged.

See:
angular/angular-cli#8284 (comment)

This change migrates all shared libs to the new
layout.

This change has several implications:

1. There is a new special `build.js` in `./shared` that builds
all shared libs in the right order. There's an alias admin-cli
taks for this but the script itself needs to live outside the
admin-cli because the admin-cli itself depends on the shared libs,
hence *building* the shared libs can not depend on the admin-cli.

2. Building the shared libs is currently quite costly. Triggering
implicitly was slowing down the build and general feedback loop
for the development. Therefore the shared libs now need to be build
explicitly. This can be done either by running `build.js` in `./shared`
or running the `build-shared` command of the admin-cli.

Notice that building the shared libs does not automatically update
the libs in client and server. For the client there is an npm script
called `updated-shared` that can be run to update the libs. However, the
server does trigger a build for the shared libs and also updated the
packages. However, since this slows down the build quite a bit this
can be skipped by passing --skip-shared` when building the server.

cburgdorf added a commit to machinelabs/machinelabs that referenced this issue Nov 6, 2017

chore(client): distribute shared libs in JS via dist
Previously our shared libs did not have a dedicated
dist folder where the compiled JS would go.

This setup introduces problems down the road and
is discouraged.

See:
angular/angular-cli#8284 (comment)

This change migrates all shared libs to the new
layout.

This change has several implications:

1. There is a new special `build.js` in `./shared` that builds
all shared libs in the right order. There's an alias admin-cli
taks for this but the script itself needs to live outside the
admin-cli because the admin-cli itself depends on the shared libs,
hence *building* the shared libs can not depend on the admin-cli.

2. Building the shared libs is currently quite costly. Triggering
implicitly was slowing down the build and general feedback loop
for the development. Therefore the shared libs now need to be build
explicitly. This can be done either by running `build.js` in `./shared`
or running the `build-shared` command of the admin-cli.

Notice that building the shared libs does not automatically update
the libs in client and server. For the client there is an npm script
called `updated-shared` that can be run to update the libs. However, the
server does trigger a build for the shared libs and also updated the
packages. However, since this slows down the build quite a bit this
can be skipped by passing --skip-shared` when building the server.
@emazv72

This comment has been minimized.

Show comment
Hide comment
@emazv72

emazv72 Nov 6, 2017

I can report a similar issue:

I have a standard, cli generated, folder structure ( Windows platform )
I simply share some modules between different applications at the source level.

Under src there are the following folders:

  • app
  • packages ( simlink )

Under packages:

  • combo-components
  • ....

Each folder is a module ( proper module.ts ) and has an index.ts for the exports.

tsconfig.json looks like this:

"compilerOptions": {
    "baseUrl": "src",
    "paths": {
      "@combo-components/core": [
        "packages/combo-components/src"
      ],
      "@catol/core": [
        "packages/catol-core/src"
      ]
    }

An import statement looks like this:
import { DataSourceResult, NotificationService } from '@combo-components/core';

It worked fine till angular 4.x and cli 1.4.x
After upgrading to 5.0 & cli 1.5.0, ng build fails with the following error:

ERROR in ../catol/combo-components/src/index.ts
Module build failed: Error: C:\Users...\workspace\catol\combo-components\src\index.ts is not part of the compilation. Please make sure it is in your tsconfig via the 'files' or 'include' property.
at AngularCompilerPlugin.getCompiledFile (C:\Users...\workspace\playground\node_modules@ngtools\webpack\src\angular_compiler_plugin.js:624:23)
at plugin.done.then (C:\Users...\workspace\playground\node_modules@ngtools\webpack\src\loader.js:467:39)
@ ./src/app/app.module.ts 13:0-63
@ ./src/main.ts
@ multi ./src/main.ts

Casing checked, also added the include property suggested by @filipesilva

{
  "extends": "../tsconfig.json",
  "compilerOptions": {
    // ...
  },
  "include": [
    "./packages/**/*.ts"
  ],
  "exclude": [
    // ...
  ],
}

The error changes slightly:

ERROR in ./src/main.ts
Module build failed: Error: C:\Users...\workspace\playground\src\main.ts is not part of the compilation output. Please check the other error messages for details.
at AngularCompilerPlugin.getCompiledFile (C:\Users...\workspace\playground\node_modules@ngtools\webpack\src\angular_compiler_plugin.js:629:23)
at plugin.done.then (C:\Users...\workspace\playground\node_modules@ngtools\webpack\src\loader.js:467:39)
at process._tickCallback (internal/process/next_tick.js:109:7)
@ multi ./src/main.ts
ERROR in ./src/polyfills.ts
...

Adding main&polyfill to the include path doesn't help either.

emazv72 commented Nov 6, 2017

I can report a similar issue:

I have a standard, cli generated, folder structure ( Windows platform )
I simply share some modules between different applications at the source level.

Under src there are the following folders:

  • app
  • packages ( simlink )

Under packages:

  • combo-components
  • ....

Each folder is a module ( proper module.ts ) and has an index.ts for the exports.

tsconfig.json looks like this:

"compilerOptions": {
    "baseUrl": "src",
    "paths": {
      "@combo-components/core": [
        "packages/combo-components/src"
      ],
      "@catol/core": [
        "packages/catol-core/src"
      ]
    }

An import statement looks like this:
import { DataSourceResult, NotificationService } from '@combo-components/core';

It worked fine till angular 4.x and cli 1.4.x
After upgrading to 5.0 & cli 1.5.0, ng build fails with the following error:

ERROR in ../catol/combo-components/src/index.ts
Module build failed: Error: C:\Users...\workspace\catol\combo-components\src\index.ts is not part of the compilation. Please make sure it is in your tsconfig via the 'files' or 'include' property.
at AngularCompilerPlugin.getCompiledFile (C:\Users...\workspace\playground\node_modules@ngtools\webpack\src\angular_compiler_plugin.js:624:23)
at plugin.done.then (C:\Users...\workspace\playground\node_modules@ngtools\webpack\src\loader.js:467:39)
@ ./src/app/app.module.ts 13:0-63
@ ./src/main.ts
@ multi ./src/main.ts

Casing checked, also added the include property suggested by @filipesilva

{
  "extends": "../tsconfig.json",
  "compilerOptions": {
    // ...
  },
  "include": [
    "./packages/**/*.ts"
  ],
  "exclude": [
    // ...
  ],
}

The error changes slightly:

ERROR in ./src/main.ts
Module build failed: Error: C:\Users...\workspace\playground\src\main.ts is not part of the compilation output. Please check the other error messages for details.
at AngularCompilerPlugin.getCompiledFile (C:\Users...\workspace\playground\node_modules@ngtools\webpack\src\angular_compiler_plugin.js:629:23)
at plugin.done.then (C:\Users...\workspace\playground\node_modules@ngtools\webpack\src\loader.js:467:39)
at process._tickCallback (internal/process/next_tick.js:109:7)
@ multi ./src/main.ts
ERROR in ./src/polyfills.ts
...

Adding main&polyfill to the include path doesn't help either.

adrianboisart pushed a commit to adrianboisart/template that referenced this issue Jan 28, 2018

AK
Important to work with shared as npm link: "preserveSymlinks": true
(sinon erreur de compilation de typescript,
    même si on a mis les paths des npm linked shared modules dans la partie output de tsconfig.json)
angular/angular-cli#8284
@AndreiLucaci

This comment has been minimized.

Show comment
Hide comment
@AndreiLucaci

AndreiLucaci Jan 29, 2018

Also, if working with ASP.Core 2.0 template, the src folder is renamed to ClientApp so in that case you should add it to your tsconfig.json file:

{
  "compilerOptions": {
    // stuff
  },
  "include": [
    "./ClientApp/**/*.ts"
  ]
}

AndreiLucaci commented Jan 29, 2018

Also, if working with ASP.Core 2.0 template, the src folder is renamed to ClientApp so in that case you should add it to your tsconfig.json file:

{
  "compilerOptions": {
    // stuff
  },
  "include": [
    "./ClientApp/**/*.ts"
  ]
}
@b-johnse

This comment has been minimized.

Show comment
Hide comment
@b-johnse

b-johnse Jan 30, 2018

I have a large enterprise app with the "code sharing" setup mentioned above. Essentially there are lazy routes defined that load feature modules, these modules are shells that in turn import from node_modules where the actual feature modules (in module.ts files via index.ts barrels) are pulled in from our internal npme/nexus. Worked like a champ with Ng4 and enabled our distributed development across multiple teams/repos.

With Ng5, after updating the tsconfig files, it will work in JiT (ng serve and ng build).

AoT will build, but when the app is started a "Uncaught TypeError: ctor is not a constructor" is thrown immediately .

b-johnse commented Jan 30, 2018

I have a large enterprise app with the "code sharing" setup mentioned above. Essentially there are lazy routes defined that load feature modules, these modules are shells that in turn import from node_modules where the actual feature modules (in module.ts files via index.ts barrels) are pulled in from our internal npme/nexus. Worked like a champ with Ng4 and enabled our distributed development across multiple teams/repos.

With Ng5, after updating the tsconfig files, it will work in JiT (ng serve and ng build).

AoT will build, but when the app is started a "Uncaught TypeError: ctor is not a constructor" is thrown immediately .

@stofte

This comment has been minimized.

Show comment
Hide comment
@stofte

stofte Jan 31, 2018

Seems silly that we have to include files that are normally part of the build. Currently my whatever is complaining that " \src\main.ts is missing from the TypeScript compilation." but that's the very very first file angular looks at, so that seems strange.

Oh well.

stofte commented Jan 31, 2018

Seems silly that we have to include files that are normally part of the build. Currently my whatever is complaining that " \src\main.ts is missing from the TypeScript compilation." but that's the very very first file angular looks at, so that seems strange.

Oh well.

@plamf

This comment has been minimized.

Show comment
Hide comment
@plamf

plamf Feb 2, 2018

@filipesilva

You have TS files in your node_modules. This really goes against how libraries should be packaged: libraries should never ship their source .ts files.

What exactly do you mean? We use ng-packagr, which ships *.d.ts files and we thought that is the right way to deliver a package.

plamf commented Feb 2, 2018

@filipesilva

You have TS files in your node_modules. This really goes against how libraries should be packaged: libraries should never ship their source .ts files.

What exactly do you mean? We use ng-packagr, which ships *.d.ts files and we thought that is the right way to deliver a package.

@benelliott

This comment has been minimized.

Show comment
Hide comment
@benelliott

benelliott Feb 2, 2018

@plamf Shipping *.d.ts is fine, it is shipping the original source *.ts files that is not.

benelliott commented Feb 2, 2018

@plamf Shipping *.d.ts is fine, it is shipping the original source *.ts files that is not.

@BBaysinger

This comment has been minimized.

Show comment
Hide comment
@BBaysinger

BBaysinger Feb 4, 2018

Well we’re not ‘shipping’ anything. This is an internal library for which we have control over which compliler we use. So packaging for distribution is a unnecessary step. We did figure out how to import it with straight .ts files, as the SO question was answered satisfactorily.

BBaysinger commented Feb 4, 2018

Well we’re not ‘shipping’ anything. This is an internal library for which we have control over which compliler we use. So packaging for distribution is a unnecessary step. We did figure out how to import it with straight .ts files, as the SO question was answered satisfactorily.

@ORESoftware

This comment has been minimized.

Show comment
Hide comment
@ORESoftware

ORESoftware Feb 15, 2018

I have this issue....this issue sucks :(

this is how I solved it for local development:

https://stackoverflow.com/questions/48797135/missing-ts-files-due-to-npm-link/48798373#48798373

ORESoftware commented Feb 15, 2018

I have this issue....this issue sucks :(

this is how I solved it for local development:

https://stackoverflow.com/questions/48797135/missing-ts-files-due-to-npm-link/48798373#48798373

@kaushikdighe

This comment has been minimized.

Show comment
Hide comment
@kaushikdighe

kaushikdighe Feb 16, 2018

@filipesilva. I am facing the same issue Just to summarize, we have a large project. So 1 project is used as library and sits in the node_modules folder. When on Angular 4 it works fine but when upgraded it is throwing me this error: Module build failed: XXX file is missing in Typescript compilation. Please make sure it is in your tsconfig via the 'files' or 'include' property. I have read this whole ticket and specially implemented what you suggested of manually adding it in tsconfig.json. But when I do that it prompts me a different error: Unknown compiler option 'include' and 'exclude'. It would be great help if you could get me out of this issue. Thank you in advance. Just to reiterate I have read through the whole blog and tried different solutions it does not seem to work. Again Thank you in advance.

kaushikdighe commented Feb 16, 2018

@filipesilva. I am facing the same issue Just to summarize, we have a large project. So 1 project is used as library and sits in the node_modules folder. When on Angular 4 it works fine but when upgraded it is throwing me this error: Module build failed: XXX file is missing in Typescript compilation. Please make sure it is in your tsconfig via the 'files' or 'include' property. I have read this whole ticket and specially implemented what you suggested of manually adding it in tsconfig.json. But when I do that it prompts me a different error: Unknown compiler option 'include' and 'exclude'. It would be great help if you could get me out of this issue. Thank you in advance. Just to reiterate I have read through the whole blog and tried different solutions it does not seem to work. Again Thank you in advance.

@kaushikdighe

This comment has been minimized.

Show comment
Hide comment
@kaushikdighe

kaushikdighe Feb 20, 2018

@andi-wr Thank you for the solution but it still does not work. It gives me whole lot of errors. Saying cannot find name 'describe'; cannot find name 'beforeEach' etc in all the files. This is a huge list of errors.

kaushikdighe commented Feb 20, 2018

@andi-wr Thank you for the solution but it still does not work. It gives me whole lot of errors. Saying cannot find name 'describe'; cannot find name 'beforeEach' etc in all the files. This is a huge list of errors.

@princeprathap

This comment has been minimized.

Show comment
Hide comment
@princeprathap

princeprathap Mar 1, 2018

@filipesilva
I am getting the below error and the third party literary do not have .ts file. can you help

ERROR in ./node_modules/agm-direction/src/agm-direction.module.ts
Module build failed: Error: D:\TandT\TandTSrc\node_modules\agm-direction\src\agm-direction.module.ts is missing from the TypeScript compilation. Please make sure it is in your tsconfig via the 'files' or 'include' property.
The missing file seems to be part of a third party library. TS files in published libraries are often a sign of a badly packaged library. Please open an issue in the library repository to alert its author and ask them to package the library using the Angular Package Format (https://goo.gl/jB3GVv).
at AngularCompilerPlugin.getCompiledFile (D:\TandT\TandTSrc\node_modules@ngtools\webpack\src\angular_compiler_plugin.js:656:23)
at plugin.done.then (D:\TandT\TandTSrc\node_modules@ngtools\webpack\src\loader.js:467:39)
at
at process._tickCallback (internal/process/next_tick.js:169:7)
@ ./node_modules/agm-direction/index.js 6:9-46
@ ./src/app/app.module.ts
@ ./src/main.ts
@ multi ./src/main.ts

princeprathap commented Mar 1, 2018

@filipesilva
I am getting the below error and the third party literary do not have .ts file. can you help

ERROR in ./node_modules/agm-direction/src/agm-direction.module.ts
Module build failed: Error: D:\TandT\TandTSrc\node_modules\agm-direction\src\agm-direction.module.ts is missing from the TypeScript compilation. Please make sure it is in your tsconfig via the 'files' or 'include' property.
The missing file seems to be part of a third party library. TS files in published libraries are often a sign of a badly packaged library. Please open an issue in the library repository to alert its author and ask them to package the library using the Angular Package Format (https://goo.gl/jB3GVv).
at AngularCompilerPlugin.getCompiledFile (D:\TandT\TandTSrc\node_modules@ngtools\webpack\src\angular_compiler_plugin.js:656:23)
at plugin.done.then (D:\TandT\TandTSrc\node_modules@ngtools\webpack\src\loader.js:467:39)
at
at process._tickCallback (internal/process/next_tick.js:169:7)
@ ./node_modules/agm-direction/index.js 6:9-46
@ ./src/app/app.module.ts
@ ./src/main.ts
@ multi ./src/main.ts

@tapaz1

This comment has been minimized.

Show comment
Hide comment
@tapaz1

tapaz1 Mar 5, 2018

I don't know if people are still having this problem - here's how I fixed the issue.

I have 2 tsconfig.json files, one at the root of the app, and the other inside the src folder (one level down from the root) named tsconfig.app.json that extends the main tsconfig.json. I explicitly added the package that I needed that wasn't being transpiled by Typescript in the "include" array, and like a lot of people here I was getting the *.spec.ts files included despite having them in "exclude" option, so I removed it from the tsconfig.json. The fix was adding the "exclude" option to the second (extended) tsconfig.app.json file. Doing that fixes the Typescript errors and lets me run ng serve without issue.

Here is tsconfig.json:

{
"compileOnSave": false,
"compilerOptions": {
"baseUrl": "./src",
"outDir": "./dist",
"sourceMap": true,
"declaration": false,
"moduleResolution": "node",
"emitDecoratorMetadata": true,
"experimentalDecorators": true,
"target": "es5",
"typeRoots": [
"node_modules/@types"
],
"lib": [
"es2017",
"dom"
],
},
"include": [
"./src",
"node_modules/your_package"
]
}

And tsconfig.app.json:

{
"extends": "../tsconfig.json",
"compilerOptions": {
"outDir": "../dist",
"baseUrl": "./",
"module": "es2015",
"types": []
},
"exclude": [
"../node_modules/your_package/**/*.spec.ts"
]
}

For some reason adding the exclude in the extended tsconfig (tsconfig.app.json) file is the only way I was able to get it to not complain about the spec files.

Based on the comments from @filipesilva this may still be a bug but it worked for me. Hopefully this helps anyone facing the same issue.

tapaz1 commented Mar 5, 2018

I don't know if people are still having this problem - here's how I fixed the issue.

I have 2 tsconfig.json files, one at the root of the app, and the other inside the src folder (one level down from the root) named tsconfig.app.json that extends the main tsconfig.json. I explicitly added the package that I needed that wasn't being transpiled by Typescript in the "include" array, and like a lot of people here I was getting the *.spec.ts files included despite having them in "exclude" option, so I removed it from the tsconfig.json. The fix was adding the "exclude" option to the second (extended) tsconfig.app.json file. Doing that fixes the Typescript errors and lets me run ng serve without issue.

Here is tsconfig.json:

{
"compileOnSave": false,
"compilerOptions": {
"baseUrl": "./src",
"outDir": "./dist",
"sourceMap": true,
"declaration": false,
"moduleResolution": "node",
"emitDecoratorMetadata": true,
"experimentalDecorators": true,
"target": "es5",
"typeRoots": [
"node_modules/@types"
],
"lib": [
"es2017",
"dom"
],
},
"include": [
"./src",
"node_modules/your_package"
]
}

And tsconfig.app.json:

{
"extends": "../tsconfig.json",
"compilerOptions": {
"outDir": "../dist",
"baseUrl": "./",
"module": "es2015",
"types": []
},
"exclude": [
"../node_modules/your_package/**/*.spec.ts"
]
}

For some reason adding the exclude in the extended tsconfig (tsconfig.app.json) file is the only way I was able to get it to not complain about the spec files.

Based on the comments from @filipesilva this may still be a bug but it worked for me. Hopefully this helps anyone facing the same issue.

@fengerzh

This comment has been minimized.

Show comment
Hide comment
@fengerzh

fengerzh Mar 9, 2018

@tapaz1 By following your instruction, I got it work. I added a section of include in tsconfig.json to include the failed module as below:

"include": ["./src", "node_modules/@jaspero/ng2-select"]

then build success. Thank you!

fengerzh commented Mar 9, 2018

@tapaz1 By following your instruction, I got it work. I added a section of include in tsconfig.json to include the failed module as below:

"include": ["./src", "node_modules/@jaspero/ng2-select"]

then build success. Thank you!

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Mar 22, 2018

The error also happens when you have the url of a main file wrong in the package.json in your library

ghost commented Mar 22, 2018

The error also happens when you have the url of a main file wrong in the package.json in your library

@jdthorpe

This comment has been minimized.

Show comment
Hide comment
@jdthorpe

jdthorpe Apr 12, 2018

we used to compile all files, essentially ignoring what tsconfig listed. This was a bug

IMHO, the new behavior of failing when the compiler wasn't asked to compile a file it wasn't supposed to compile in the first place is also a bug.

we don't really support using incorrectly packaged libraries

npm link is supported by, well, NPM, so it seems odd that angular doesn't. In particular, I've got this in in my .npmignore:

*.ts
!*.d.ts

So that TypeScript files are not included when I npm publish. Perhaps angular could also respect .npmignore files ,and only complain when a .ts file that would be included in a published package is encountered. This would resolve the problems that devs who co-develop an angular site and a related npm package have with this new behavior.


I realize that my situation may be more complicated than most. I've got an angular app and 3 independent NPM packages that I'm working on, where my app depends on all 3 packages, and one of the packages depends on the other two. Two days of googling, RTFMing, and trying every combination of exclude:["foo","bar","bat"] haven't worked for me. (thought oddly "including" them does work, though it brings up another host of other errors b/c I use different versions fo pacakges in my dependences, so there are collisions with the typings between my app's dependencies and my dependencies dependencies.)

In the end, I npm pack'ed my dependencies, installed them in my app from the built .tgz files, put build scripts in my package.json for all my dependencies like so:

npm pack && pushd /my/app/ && npm i /my/dependency/dependency.tgz && popd

all because of this paternalisticl error, that obstructs the use of npm link -- which is a mode of development tool explicitly supported by NPM!

In future, can this be warning instead of an error, or perhaps add a cli flag indicating that no error should be raised just because angular wasn't asked to compile every .ts file it can find?


Workaround:

This error is thrown when loading .js files and .map files, and not when deciding which .ts files to compile. Hence, if:

  • you are using npm link or npm i file:/my/other/package to co-develop an angular app and a node package and
  • you have "sourceMap": true, in the compiler options of your linked package, and
  • you have called tsc in your linked repo,

then you can go to the line that threw the error, which is listed in the output from ng serve and comment out the line throw new Error(msg);, and you're off to the races.

The downside to this workaround is that while your ng-serveer will reload your app every time you make changes in your dependency projects -- but it won't compile them and you'll have to restart ng-serve after calling tsc in your dependency in order for updates in your dependencies to be picked up.

In short, the workaround sucks, but at least it doesn't prevent you from doing development on separate projects with separate dependencies and typings.

jdthorpe commented Apr 12, 2018

we used to compile all files, essentially ignoring what tsconfig listed. This was a bug

IMHO, the new behavior of failing when the compiler wasn't asked to compile a file it wasn't supposed to compile in the first place is also a bug.

we don't really support using incorrectly packaged libraries

npm link is supported by, well, NPM, so it seems odd that angular doesn't. In particular, I've got this in in my .npmignore:

*.ts
!*.d.ts

So that TypeScript files are not included when I npm publish. Perhaps angular could also respect .npmignore files ,and only complain when a .ts file that would be included in a published package is encountered. This would resolve the problems that devs who co-develop an angular site and a related npm package have with this new behavior.


I realize that my situation may be more complicated than most. I've got an angular app and 3 independent NPM packages that I'm working on, where my app depends on all 3 packages, and one of the packages depends on the other two. Two days of googling, RTFMing, and trying every combination of exclude:["foo","bar","bat"] haven't worked for me. (thought oddly "including" them does work, though it brings up another host of other errors b/c I use different versions fo pacakges in my dependences, so there are collisions with the typings between my app's dependencies and my dependencies dependencies.)

In the end, I npm pack'ed my dependencies, installed them in my app from the built .tgz files, put build scripts in my package.json for all my dependencies like so:

npm pack && pushd /my/app/ && npm i /my/dependency/dependency.tgz && popd

all because of this paternalisticl error, that obstructs the use of npm link -- which is a mode of development tool explicitly supported by NPM!

In future, can this be warning instead of an error, or perhaps add a cli flag indicating that no error should be raised just because angular wasn't asked to compile every .ts file it can find?


Workaround:

This error is thrown when loading .js files and .map files, and not when deciding which .ts files to compile. Hence, if:

  • you are using npm link or npm i file:/my/other/package to co-develop an angular app and a node package and
  • you have "sourceMap": true, in the compiler options of your linked package, and
  • you have called tsc in your linked repo,

then you can go to the line that threw the error, which is listed in the output from ng serve and comment out the line throw new Error(msg);, and you're off to the races.

The downside to this workaround is that while your ng-serveer will reload your app every time you make changes in your dependency projects -- but it won't compile them and you'll have to restart ng-serve after calling tsc in your dependency in order for updates in your dependencies to be picked up.

In short, the workaround sucks, but at least it doesn't prevent you from doing development on separate projects with separate dependencies and typings.

dond2clouds added a commit to d2clouds/speedray-cli that referenced this issue Apr 23, 2018

kresiak pushed a commit to kresiak/help that referenced this issue Apr 26, 2018

ak
Important to work with shared as npm link: "preserveSymlinks": true
(sinon erreur de compilation de typescript,
    même si on a mis les paths des npm linked shared modules dans la partie output de tsconfig.json)
angular/angular-cli#8284


git-svn-id: https://github.com/kresiak/template.git/trunk@2 2c0367cd-f7dd-5941-2a14-ce57b7db7bff
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment