Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[v1] Working with third-party dependencies #129

dherges opened this issue Sep 21, 2017 · 1 comment

[v1] Working with third-party dependencies #129

dherges opened this issue Sep 21, 2017 · 1 comment


Copy link

@dherges dherges commented Sep 21, 2017


By default, ng-packagr brings a configuration that works well with Angular and RxJS packages. However, other third-party libraries need custom configuration. Users have encountered several issues. There are also different use cases for working with third parties. This issue tries to keep an overview of those issues.

Please keep posting issues for individual / specific questions.

Use Cases for Third-Party Libraries

  1. 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.
  2. 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.
  3. 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.

Related Issues

How should external dependencies be handled in package.json

#135 asks how external dependencies of an Angular library should be handled in package.json. When should it be added to peerDependencies? When to devDependencies? Where should the package.json be placed? Answer

Understanding the npm dependency model by Alexis King

Configuring lib.externals in ng-package.json

#85 asks for configuring lib.externals for third-party libraries. Several examples and an explanation for the module id are given.

#119 asks how to configure the lib.externals. An explanation of the underlying rollup mechanics is given.

#135 also asks how to configure lib.externals. Another try of an explanation and how to find out the module ID.

#108 is a RxJS-specific custom addition to lib.externals

#142 asks how to configure lib.externals with primeng: solution

#230 shows how to configure with firebase


#290 asks how moment.js can be used with the ngc / tsc / rollup tech stack. Answer is given. Issue solved!

#163 asks how to configure lib.externals for moment.js. An explanation how to figure out the configuration is given.

TypeScript import paths

#101 and #118 describe an issue with import { .. } from '@foo/bar' and import { .. } from '@foo/bar/index'. Workaround is provided.

#117 describes an issue when embedding your library in a monorepo application. Solution: symlink or copying to local node_modules

In the discussion of #117, an issue with deep import paths is described because VSCode auto-suggests the deep import path (from source file structure).

Regression for embedding a global-scoped third-party library in ng-packagr 1.2.0

In PR #121, generic support for rollup-plugin-commonjs was introduced. This can lead to a regression. Prior to ng-packagr 1.2.0, it was possible to embed a third-party library that would register itself on the global scope (e.g. window['FooBar']). As of ng-packagr 1.2.0, this no longer works as the embedded third-party library will be "wrapped up" in a commonjs module definition.

Please refer to the discussion in #121 for detail and a migration solution


#62 asks for generic commonjs support

@ng-packagr ng-packagr locked and limited conversation to collaborators Sep 21, 2017
@dherges dherges changed the title Working with third-party dependencies [v1] Working with third-party dependencies Jan 23, 2018
@dherges dherges added the v1 label Feb 21, 2018
Copy link
Member Author

@dherges dherges commented Feb 21, 2018

Closing this now as the q&a's are related to v1.

@dherges dherges closed this Feb 21, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant