feat: support of external libraries/components in dist-custom-elements

[MarkChrisLevy]

Prerequisites

• [X] I have read the Contributing Guidelines.
• [X] I agree to follow the Code of Conduct.
• [X] I have searched for existing issues that already include this feature request, without success.

Describe the Feature Request

When building components with dist-custom-elements we may need to share code with other components/apps or use external libraries. Currently every external library that is included within a component will be bundled in the compilation output.

It extends FR described in #3226 and follows the discussion in #3136.

Describe the Use Case

There are two use cases:

1. Marking, that a library, that is used by a component should not be packed in the component's output bundle
2. Marking, that an external lazy loaded component that is used by a component should not be packed in the component's output bundle

In the first case, lets say that we have a dependency to moment.js - right now, if you build a component and within the code of the component there are imports from moment.js, then all required code from moment.js (and its dependencies) will be put in the output bundle. That is fine and proper default behavior, but in my case moment.js is used across multiple components and within main project (which imports those components), moment.js is also directly imported so I would end up with moment.js being bundled three times. Having an "external" option in dist-custom-elements will allow to avoid that.

Second case, lets say, that we created a component, that uses @ionic/core lazy loaded component, e.g. ion-button. If you build the component, you will have in the output bundle the ion-button code but also other ionic components (whole collection is consumed). Having an "external" option would tell rollup to treat @ionic/core as external but also to treat stencil collections as external components.

Describe Preferred Solution

In dist-custom-elements we need to create new option "external":

export interface OutputTargetDistCustomElements extends OutputTargetBaseNext {
   ...
   external?: (string | RegExp)[];
   ...
}

Value of the external is directly passed to rollup (array of string or RegExp) - this will fully solve the first case (importing external library). Additionally, somewhere in dist-custom-elements compilation process, Stencil must check if lazy components collection is also to be treated as external.

In my Stencil fork both of those cases are covered in dist-custom-elements-bundle output target, below you may see what changes I had to make in order to make it work:

• https://github.com/CODE-AND-MORE/stencil/blob/7c4d13be238fe76abc097c07ddc7b305bfe0383e/src/compiler/bundle/bundle-interface.ts#L13
• https://github.com/CODE-AND-MORE/stencil/blob/7c4d13be238fe76abc097c07ddc7b305bfe0383e/src/compiler/bundle/bundle-output.ts#L98
• https://github.com/CODE-AND-MORE/stencil/blob/7c4d13be238fe76abc097c07ddc7b305bfe0383e/src/compiler/output-targets/dist-custom-elements-bundle/index.ts#L58
• https://github.com/CODE-AND-MORE/stencil/blob/7c4d13be238fe76abc097c07ddc7b305bfe0383e/src/compiler/output-targets/dist-custom-elements-bundle/index.ts#L140-L145

Describe Alternatives

First case (importing external library, not lazy component) can be resolved with rollup plugin defined in stencil.config.ts:

export function externalsPlugin(externals: (string | RegExp)[]) {
    return {
        id: "externalsPlugin",
        resolveId(id: string) {
            for (const e of externals) {
                if ((typeof e === "string" && id === e) || (e instanceof RegExp && e.exec(id))) {
                    return {id, external: true}
                }
            }
        }
    }
}

Related Code

No response

Additional Information

No response