No components, pipes, etc. found from within an Angular CLI library

[arobinson]

I just refactored our code to use an Angular library. At runtime, everything is working and rendered correctly, but this VSCode extension is saying that none of the components, directives, pipes, etc. can be found when the template HTML is open.

Example error:

nw-messages' is not a known element:
1. If 'nw-messages' is an Angular component, then verify that it is part of this module.
2. If 'nw-messages' is a Web Component then add 'CUSTOM_ELEMENTS_SCHEMA' to the '@NgModule.schemas' of this component to suppress this message.

And:

The pipe 'NwTranslationPipe' could not be found Angular

Our project layout is an Angular 7 (CLI) application with an Angular Library child project. None of the items from the Angular library are being found by this extension. Components from the application are found, it is only the library ones that are not working.

Once I get a chance I'll create a project on (like github) to reproduce the issue

Are there any known issues with this extension and using an Angular library in a child project of an angular application?

[arobinson]

Application to reproduce the issue:
https://github.com/arobinson/vscodeNgLanguageService340

Follow the steps in the readme to see the issue

[JohnnyDevNull]

You have to build it first, then reload VSCode. After this steps it should work, but keep in mind that the build files are locked after it, so you have to "Reload > Remove Build > Rebuild > Reload" in this cycle... it is a bad workflow i know, but actually the plugin locks the files with the duplicate TSServer running.

[Urastor]

Having the same problem when using RouterModule. I have an app-module with an app-routing-module and import a feature-module with a feature-routing-module. In my feature-component template, I can't find any references to any directives or pipes. I even get an error. Running the app works fine.

[kyliau]

Possible root cause: #457

[granttw]

I am having a similar experience with a slight difference.

I created a project very similar to @arobinson. A workspace with a library project and an application project. I take advantage of the tsconfig.json path maps and import the library module without publishing it to npm. If I build the library before adding the import to the application, everything works fine. If I add a new component to the library, build, and try to use it in the application, I get the error that says it does not exists.

If I delete the dist folder for the library build and rebuild and restart visual studio code, the error goes away. This is what I believe @JohnnyDevNull was saying.

Is this expected behavior? Am I doing something incorrectly? If this is expected behavior, it seems like this makes the --watch option on the ng build command for the library useless.

@kyliau - can you please confirm if this is expected behavior? Thanks.

I am having trouble understanding why #457 and #244 apply here. I don't think either of those apply to my scenario.

[kyliau]

@granttw Based on your description, it looks like the language service is not picking up new metadata.json from the library after a new component is added.
The reason is because we are only watching for changes in d.ts file. When a new component is added and compiled, the new .d.ts file gets picked up, but not the corresponding metadata.json.

I can think of two possible solutions:

1. Reload metadata.json when the .d.ts file changes
2. Wait for Ivy integration, at which point metadata.json is no longer needed.

I'll explore (1) for now and see how much work it takes to fix this.

[JohnnyDevNull]

@granttw you do everything right, that's the actual workflow with VSCode when developing with a local library, only WebStorm does it a bit better, but also there I have to reload in some edge cases.

[kuncevic]

Same here. I have a monorepo setup with angular material module living in my shared library.
So I've got that weird error withing in templates templates on each material component. #14 (comment)

[alberto-chiesa]

This is impacting our workflow pretty severely. It's strange, but it used to work before 0.900. Does someone knows of any workarounds to get the library discovery work again?
Having lots of components and directives in a library means that a lot of code is reported as errors, but the compilation (both via serve and build) works just fine.
I tried to build with --prod option, but to no changes whatsoever on the error message.

[kyliau]

@alberto-chiesa Did you compile your library with flatModuleOutFile? Could you please check or paste your angular.json?

[alberto-chiesa]

@kyliau nope. Should I? Sure, I can copy and paste the angular.json, but it's pretty large(ish): 80KB.
But AFAICT, that option shouldn't go in tsconfig.lib.json?

[alberto-chiesa]

Btw, here it is my tsconfig.lib.json for the referenced library:
tsconfig.lib.json.txt

And the base tsconfig in the root:
tsconfig.json.txt

[mtgibbs]

I actually have a similar problem with a pipe in from a shared library when adding it to my shared.module.ts in the project I'm trying to use it in (Pretty much what was described in #98 ). While it compiles and runs perfectly fine, VS Code complains about it.

I grabbed a screenshot of a simple component with my pipe showing an error. I can probably make up an example project that shows this. This is with compiling my library project with your suggested flatModuleOutFile option in tsconfig.

Edit: Looks like @arobinson already took care of an example

[PostImpatica]

@alberto-chiesa You can uninstall the extension for now, this is what I did.

[JohnnyDevNull]

Maybe this could help you out:

      "@your/library": [
        "dist/your-library",
        "projects/your-library/src",
      ]
      "@your/library/*": [
        "dist/your-library/*",
        "projects/your-library/*",
      ]

Extend the above to your path mapping in your main tsconfig.ts so that the local source get's collected when there is no build available. This improves the library development a lot, because you don't need to build it first. There is only one additional tweak left to get this working:

1. put a index.ts next to your public_api.ts and move all re-exports from the public_api.ts to the index.ts
2. re-export all from the index.ts in the public_api.ts

Then your local mapping works like a charm! Otherwise you have to follow the workflow describe here: #340 (comment)

EDIT: The second path is for subentry points.

[18clans]

I ran into this same issue where my custom pipes was not found. Take a look at my post #888 to see if it'll resolve yours since I got mine resolved.

[kyliau]

This has been fixed by the new Ivy-native language service, released in v11.1.0.
It's an opt-in feature for now, please give it a try and let us know if you have any feedback.
For the best editor experience, please make sure your project has strictTemplates enabled in angularCompilerOptions.
In case you run into similar bug, please file a new issue. I'll close this for now.

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