Versions:
It seems that exports from modules that are imported into the main AppModule are not being picked up correctly.
See the following gist: https://gist.github.com/petebacondarwin/9fb71ae5efd2ad1567938db1350f5a9f
In this example the BangPipe is being declared and exported from the SharedModule, which is then being imported into AppModule, which contains the AppComponent. The AppComponent is using the BangPipe in its template.
Putting this inside a vanilla Angular CLI generated project will build (with --prod and --aot flags) successfully but VS Code is reporting that this pipe is not found.
Declaring the BangPipe in the AppComponent resolves the error.
It seems that the Language Service is not walking the module imports to identify what pipes are available. It is possible that this also affects components too.
Please re-open if you can reproduce in 0.1.0
I'm seeing this issue currently with v0.1.3. Everything compiles (angular cli) and runs as expected. I don't think I'm doing anything wrong on my end, but to be sure...
My SharedModule declares and exports my base components:
import { ...all the things } ...
@NgModule({
imports: [...],
declarations: [
...SHARED_COMPONENTS,
...SHARED_DIRECTIVES,
...SHARED_PIPES,
],
exports: [
...SHARED_COMPONENTS,
...SHARED_PIPES,
]
})
export class SharedModule {
static forRoot(): ModuleWithProviders {
return {
ngModule: SharedModule,
providers: [
...SHARED_SERVICES,
...SHARED_GUARDS,
]
};
}
}
My AppModule imports SharedModule.forRoot()
@NgModule({
declarations: [...],
imports: [
...,
SharedModule.forRoot(),
...
],
providers: [ ],
bootstrap: [
AppComponent
]
})
My UsersModule imports SharedModule, UsersRoutingModule and USERS_COMPONENTS
...
import { SharedModule } from 'app/shared/shared.module';
import { UsersRoutingModule, USERS_COMPONENTS } from './users-routing.module';
@NgModule({
imports: [
...,
SharedModule,
UsersRoutingModule,
...
],
declarations: [
...USERS_COMPONENTS
],
providers: [...]
})
My UsersIndexComponent works, but intellisense gives me "[component] is not a known element" for all components from the SharedModule

@chuckjaz I'd be willing to give temporary access to my private repo if that would help?
@uberspeck Can you try to narrow down what is confusing the language service in a smaller reproducible case?
@chuckjaz sure, I'll fork my repo and start yanking all the unrelated code and see if i can reproduce it on a smaller scale
@chuckjaz, i created branch (ngls-issue) on my project and invited you as a collaborator. I've stripped out everything but a few basic modules/components. You'll notice that you won't see errors on the login component that's imported directly into the AppRoutingModule, however if you view the /users/users-index/users-index.component.html you'll see the errors.
@uberspeck Is there a way that you can create a public repository from this? We are discouraged from requesting or accessing private repositories.
The issue you are running into is a variant of the baseUrl issue. The language service does not correctly respect the baseUrl option. For example, if you change the import of the shared module from app/shared/shared.module to ../shared/shared.module then the errors go away.
I should be fixing this one way or the other this week or next so this will go away. The fix is already in Angular master.
Ahh, ok. Thanks for looking into it @chuckjaz!
having the same issue as @uberspeck, is the fix already included in the current version?
@chuckjaz hi. Did you solved this issue?
Also having this problem. Is there an active PR related to this?
it displays an error (but compiles) when components from custom angular library modules are used if their module is imported like this:
import { SharedModule } from 'shared';
but errors are gone if I change import like this:
import { SharedModule } from '../../dist/shared';
Is it the same problem or should I create a new issue?
PS: the problem is relevant only to my custom components - there are no errors on material components even though they have been exported/imported through the same library module.
Having this issue in 0.1.9. Only seems to be affecting library components referenced from outside of the app's project structure, even when both project folders are loaded into vs code. e.g. referencing from "projects/shared-lib/src/public_api" shows no error, referencing from "../ngls-issue-lib/projects/ext-lib/src/public_api" can't resolve the component and shows an error.
The app builds and runs without problems, displays all components.
Reproduced in sample project at public repo:
https://github.com/rweads0520/ngls-issue.git
It is the reference in the "ngls-issue-app" project that is not resolving.
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._