Angular Libraries : Refactor Existing Components into their own folders.

Deeper into Library Internals

The Angular schematic for creating a library gives a different view of the project. This is due to it choosing to use a multi-project layout.

This is different than the traditional Angular Project because the component is not contained within it's own folder.

If we move this component into a folder and build again we first see this message. Which is just telling us which project is being compiled.

But the build immediately fails because the public.api.ts file needs to follow the change.

export * from './lib/jwp.service';
export {JwpComponent} from './lib/components/jwp.component';
export * from './lib/jwp.module';

Once we changed the file everything worked.

We learned the AOT compiler compiles that file first as no other output was seen.

The project structure is now starting to look like a 'normal' Angular component layout.

Dependencies

The node_modules Eco-system loves gigantic dependency chains, for example, download a package; like Material, and you'll find it doesn't include CDK. Manual work is needed to fix dependencies.

Library projects don't store the depenecies in app.module rather they store them in a module that matches the name of your library project. This means that the angular.json project name must match the module name in your library folder.

When moving files around, the paths to the components in the module file, are auto-updated; which is nice to have.

Compile Errors

Projects that compile normally in your other application may not compile correctly in a library project because the compiler used is more strict! It seems to find things not found using ng build in a SPA application.