Library with Typescript files fails to compile in AOT

[localyost3000]

- [x] bug report
- [ ] feature request

Versions.

node v6.10.0
npm v3.10.10
Windows 10

Repro steps.

We have a shared component library in our node_modules. We use some, but not all, of the components in our actual app. In some cases, we use a component which has another component's selector string in its template, while overriding the component referenced. When we run AoT, the errors claim that the overridden component can not be found. However, the path logged is incorrect, which is probably why it cannot be found.

eg.
node_modules/@shared/angular/components/demo/template.html is <other-component><other-component>
src/components/other/component.ts has some customized code

If we run AoT through @ngtools/webpack we get something like this:

ERROR in C:/Repos/OURAPP/client/$$_gendir/node_modules/@shared/angular/components/demo/component.ngfactory.ts (29,27): Cannot find module '../../../../../../$_gendir/src/components/other/component.ngfactory'.

Desired functionality.

I'd expect it to resolve to the correct file. removing the $$_gendir from the second path makes it point to the correct file, so clearly there's just a path resolution error somewhere.

[filipesilva]

Does this also happen if you run AOT via ngc?

[localyost3000]

@filipesilva I'm actually not sure, because ngc fails upon encountering our .less files.

[filipesilva]

We can take a look if you can create a simple repro of this issue, but off the top of my head nothing occurs to me.

[localyost3000]

@filipesilva Alright, I've pushed up a simple repo with the error present. Its pulled from our actual app then altered to remove company info and irrelevant stuff, but I'm sure there's still unused imports and stuff.

https://github.com/swimmadude66/BrokenPathNgToolsWebpack

When running the webpack AOT build via npm run webpack the error looks something like this:

ERROR in C:/Repos/Other/ngtools-test/client/$$_gendir/node_modules/@shared/angular/components/home/component.ngfactory.ts (11,26): Cannot find module '../../../../../../$_gendir/src/components/other/component.ngfactory'.

ERROR in Could not resolve "src/modules/demo/root" from "src/modules/demo/root".

[filipesilva]

@swimmadude66 the library you're using isn't AOT compatible, that is why it doesn't work. There isn't a lot of guidance around as to how build a AOT compatible library, but you can find a WIP at angular/angular#16486.

[localyost3000]

@filipesilva the library we are using is just regular ts files. We are referencing them the same way we would a local file, but inside node_modules. Please let me know why you think that the library is not AOT compatible. Its worth noting that it works perfectly fine on Angular 2.1.2, and it is only in upgrading that the errors occur.

did you look at the repo I posted above?

[filipesilva]

I did look at the repo, that's is how I identified the problem. In your package.json you are trying to install that library... but you also want to not really use it as a library, but rather as just a bunch of files your project uses.

This, unfortunately, doesn't work very well. You either have a library or you don't, and the middleground where you just have a few TS files in node_modules just doesn't work very well.

Kind of like when people publish ES6 libs to npm - if you want to use them then you'd have to do some custom config of your build system to not only build your app, but also build that library.

In the WIP guide I linked you there's a section on why you can't just publish TS files to npm that explains it a bit more.

I know you're not publishing to npm, but you're kinda of pretending your folder is a library anyway. And the problem isn't that it's on npm, it's how the library is packaged and how it's meant to be consumed.

The TLDR is that all if you want to have a library you do have to package it, just having the TS files there won't work. It might have worked on a certain setup, with certain dependencies, but that's not how libraries are meant to be consumed and thus not really a supported scenario.

I'm not trying to downplay how this sort of thing is frustrating... I know it is, and I know that guidance is scarce, and that means that it's really hard to set stuff up. On my plate is to do a CLI story on how to work with linked libs, which I hope will help.

[localyost3000]

@filipesilva alright, I understand now. Thanks for the thoughtful response. This is pretty frustrating, but I guess it makes sense that this is an edge-use case that doesn't necessarily warrant consideration in this sort of project.

My team is working on flattening our shared code in to each partner project and re-thinking how we can reuse components if not through imports.

[filipesilva]

@swimmadude66 the story I had for linked libs was merged https://github.com/angular/angular-cli/blob/master/docs/documentation/stories/linked-library.md, but bear in mind that this guidance requires at least 1.1.0-rc.0 (we changed how we resolve paths in #6276).

[filipesilva]

Also, there is a WIP guide for libraries in angular/angular#16486, sample repo at https://github.com/filipesilva/angular-quickstart-lib for now. Hope this helps.

[localyost3000]

Thanks. We just removed our shared library entirely and flattened it into each partner implementation. Its not exactly DRY, but if it wont work with the framework we chose, we will have to come up with something else.

[CSchulz]

@filipesilva Cool stuff with the guide. Are there any plans to support such library and integration configuration with the CLI as well?

[angular-automatic-lock-bot]

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.}