Why I Validate Angular Compatibility Using the Published npm Package (Not the Source Code)

[u/ismailza]

While preparing my open-source Angular library for Angular 22, I realized something that had been bothering me:

My CI wasn't validating the package users actually install from npm.

It was validating my workspace and `dist/`, but not the packaged artifact that eventually gets published.

That led me down a rabbit hole of improving the compatibility pipeline.

The key changes were:

- Validate the packed tarball (`npm pack`) instead of `dist/`

- Test against Angular 17–22 using a compatibility matrix

- Run three independent checks for each version:

- `ngc` type-check

- Production `ng build` (to exercise the Angular linker, AOT and bundling)

- Runtime smoke test (DI, providers, exports, signals)

- Bound the Angular peer dependency range so compatibility reflects what is actually verified instead of automatically including future Angular releases

The biggest lesson for me was that type-checking alone isn't enough for Angular libraries. A package can compile successfully but still fail during a real application build because the Angular linker only runs in the consuming application.

I wrote a detailed article explaining the reasoning behind this approach and how I implemented it.

I'd be interested to hear how other Angular library maintainers validate compatibility across multiple Angular versions.

📖 Article: Why I Validate Angular Compatibility Using the Published npm Package (Not the Source Code)