You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
import library module into main AppModule: import { MylibModule } from 'mylib';
Observed behavior
I'm exited by the new generation of libraries in the CLI. But I didn't got it to work initially. While the creation of build of the library seems to be taken care of, the integration into the main app seems to be missing. I believe this is caused by an incorrect reference in the path setup in the tsconfig.json, as it is configured with the following after creation of the library:
"paths": {
"mylib": ["dist/mylib"]
}
This requires an initial build to have a generated dist/mylib folder in the first place, but would also require to continuously rebuild the library upon changes.
After I change the path to the src folder:
"mylib": ["projects/mylib/src/public_api"]
I'm able to include the module without building, but also have a seamless experience upon any changes in my library component.
I know the public_api has been originated from the ng-packagr, but i'm wondering if we shouldn't change this into an ordinary index.ts, as it would make the import easier. in addition, if that file could live at the root of our generated library, the import could be shorten to "mylib": ["projects/mylib"]
Desired behavior
Change the path reference to the source rather the generated build files
(optional) simplify reference of the library by changing the public_api.ts into index.ts and move it to the root directory.
@tobi-or-not-tobi Doesn't this make ng-packagr embed this files in the builded library ?
Anyway, given the comment by @dherges (angular/devkit#730 (comment)), we could respond to this by adding some consistent "continuous library build" process. I'm on this right now for a project, so I may make a PR to angular-cli or devkit soon enough if I have time.
In fact, I don't know what's the angular-cli politic about issues related to both angular-cli and devkit (this is the case here angular/devkit#730 (comment)). @hansl@filipesilva@Brocco, do you have an opinion about opening separated issues for devkit and angular-cli vs keeping the discussion in one project only ? Should a devkit issue considered has external ?
Activity
[-]Incorrect tsconfig path for using embedded libraries[/-][+]Incorrect tsconfig path for libraries[/+]nweldev commentedon Apr 18, 2018
@tobi-or-not-tobi Doesn't this make ng-packagr embed this files in the builded library ?
Anyway, given the comment by @dherges (angular/devkit#730 (comment)), we could respond to this by adding some consistent "continuous library build" process. I'm on this right now for a project, so I may make a PR to angular-cli or devkit soon enough if I have time.
tobi-or-not-tobi commentedon Apr 19, 2018
Thanks @noelmace, let's keep the discussion in the devkit project.
nweldev commentedon Apr 19, 2018
In fact, I don't know what's the angular-cli politic about issues related to both angular-cli and devkit (this is the case here angular/devkit#730 (comment)). @hansl @filipesilva @Brocco, do you have an opinion about opening separated issues for devkit and angular-cli vs keeping the discussion in one project only ? Should a devkit issue considered has external ?
feat(@angular/cli): build only the projects of a certain type
feat(@angular/cli): build only the projects of a certain type
angular-automatic-lock-bot commentedon Sep 8, 2019
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.