Update
This warning is coming from ng-packagr
(and there's now a section of the ng-packagr docs about this). Turns out ng-packagr
is just telling you that it wants you to add all dependencies to an "allowedNonPeerDependencies": []
property in ng-package.json
(this option used to be called "whitelistedNonPeerDependencies"
).
For example:
{
"allowedNonPeerDependencies": [
"tslib",
...
]
}
Original
Just ran into this myself. This warning is coming from ng-packagr
I think (which the angular-cli relies upon to generate and package libraries). I'm not exactly sure what they mean by "whitelist," as that phrasing doesn't seem to be directly explained in ng-packagr's docs, but this issue in the ng-packagr repo has a ton of different options for how to work around the problem.
- Peers (such as Angular, RxJS): in this use case, the third-party dependency is a peerDependency of your library. Users of your library need to include both your library and the third-party library in their dependencies section.
- Embedding (e.g. legacy JS libraries): you have a legacy JavaScript library (e.g. an adapter to a proprietary backend) and you want to (need to) embed the legacy code in your library. In this case, the third-party dependency is a devDependency of your library and will be embedded into the bundle of your library.
- Mixed mode - embedded & peer (e.g. UX guidelines, Angularized styleguide): in this use case, the third-party dependency is a peerDependency but also (partially) embedded in your library. You may want to re-use existing CSS/SCSS/LESS stylesheets from the third-party library in your library, thus "embedding" code from the third-party in your library. At the same time, the third-party dependency is a peerDependency of your library.
The github issue has more info on this.
ng-package.prod.json
for being able to build the library with--prod
. – Tocology