What is the proper way to use a dependent npm package in angular 6 library project?

It looks like adding the package name to a "whitelistedNonPeerDependencies" collection in the ng-package.json file will resolve this build issue. I'm still not sure what the best practice is here though. Should we create angular libraries that have dependancies on other npm packages or is it best to only have peerDependancies?

ng-package.json file:

{
  "$schema": "../../node_modules/ng-packagr/ng-package.schema.json",
  "dest": "../../dist/ikr-lib",
  "deleteDestPath": false,
  "lib": {
    "entryFile": "src/public_api.ts"
  },
  "whitelistedNonPeerDependencies": [
    "element.ui"
  ]
}

This is more of a guess/ramble than an official answer, but here's what I gather from what I've found and thought so far.

The source code gives a clue about their reasoning:

// Verify non-peerDependencies as they can easily lead to duplicate installs or version conflicts in the node_modules folder of an application

So I think they're concerned about a scenario where you have a dependency of one version in the library itself, while the application consuming that library may have another version it uses.

Using ^ in the version is the default configuration for installing dependencies Also, using ^ in the version number will deduplicate dependencies that differ by minor or patch versions. So I think the main concern would be around major version.

A few examples from the perspective of the app's node_modules:

• App: ^2.8.3, Library: ^2.8.0 => deduplicated (2.8.3)
• App: ^2.9.0, Library: ^2.3.4 => deduplicated (2.9.0)
• App: ^3.0.1, Library: ^2.3.4 => duplicate (3.0.1 and 2.3.4 exist)

This could bloat the application size, or cause a conflict in terms of what version the tools will attempt to load as a dependency.

This answer also talks a little bit about why to use peerDependencies instead.