You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
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
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.
Description
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
peerDependency
of your library. Users of your library need to include both your library and the third-party library in theirdependencies
section.devDependency
of your library and will be embedded into the bundle of your library.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 apeerDependency
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 topeerDependencies
? When todevDependencies
? Where should thepackage.json
be placed? AnswerUnderstanding 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
Moment.js
#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'
andimport { .. } 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
Other
#62 asks for generic commonjs support
The text was updated successfully, but these errors were encountered: