[PR WELCOME] Dynamic rollup configuration // print descriptive error messages

Type of Issue

[x] Feature Request

Description

Many people seem to have the same issue with various libraries: they don’t have correct rollup externals.

How To Reproduce

Look at #310, #301, #85, #119, #108, #142, #230, #163, etc…

Expected Behaviour

I suspect that a lot of these issues can be avoided by printing a more helpful error message.

Version Information

ng-packagr: v2.x.y
node: v8.x.y
@angular: v4.x.y
rxjs:
zone.js:

[alan-agius4]

Question, why not have externals in rollup be a function like the below so that all node modules are treated as externals ?

external: id => !(path.isAbsolute(id) || id.startsWith("."));

@DavidParks8, @dherges any feedback?

[dherges]

Hm. Obviously, lib.externals was driven by rollup’s external and global settings. So that’s what it was in the past.

Now, let’s switch perspective to the present. If I, as an author or maintainer of a library, write a library depending on a third-party – import { ... } from '@foo/bar'; in TypeScript code – , then I’d like to treat the third-party as a peerDependency: { "@foo/bar": "..." } and thus a rollup external – in almost every case.

There is one exception that I found and that we use in an enterprisy case: I, as a maintainer, have legacy javascript code that I’d like to embed in the bundles of my library. Why? The legacy may not be on a npm registry, it may be monkey-patched, … that sort of enterprisy things.

Why do we keep writing external when external is the 9-out-of-10 use case? Why don’t we write embedded for things we’d like to embed and treat everything else as external by default?