CODEWITHSUNDEEP
angular6angular-library
cobolstinks
cobolstinks

Reputation: 7153

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

I'm a little confused as to how im supposed to reference external npm packages in my library angular6 project. We have an internal scss library I'd like to use to style my reusable components in my library. How do i go about importing that?

package.json for lib project:

{
  "name": "ikr-lib",
  "version": "0.0.1",
  "peerDependencies": {
    "@angular/common": "^6.0.0-rc.0 || ^6.0.0",
    "@angular/core": "^6.0.0-rc.0 || ^6.0.0",
    "document-register-element": "1.8.1"
  },
  "dependencies": {
    "element.ui": "^1.0.1"
  }
}

When I build the library project I get this:

Distributing npm packages with 'dependencies' is not recommended. Please consider adding element.ui to 'peerDependencies' or remove it from 'dependencies'.

BUILD ERROR
Dependency element.ui must be explicitly whitelisted.

Upvotes: 33

Views: 18251

Answers (3)

kumar chandraketu
kumar chandraketu

Reputation: 2370

you can whitelist using these way in your ng-package.json file:

 {
  .....
  "whitelistedNonPeerDependencies": [
    "angular" // it matches using regular expression 
  ]
 }

you can completely suppress this using below approach
{
  .....
  "whitelistedNonPeerDependencies": [
    "."
  ]
 }

Upvotes: 1

pseudoramble
pseudoramble

Reputation: 2561

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.

Upvotes: 13

cobolstinks
cobolstinks

Reputation: 7153

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"
  ]
}

Upvotes: 18

Related Questions