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

Abierto
#3,576 3 comentarios 8 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
typescript
Área
build-system

Línea de trabajo

Comienza con src/declarations/stencil-public-compiler.ts y los archivos vinculados bundle-interface.ts, bundle-output.ts y dist-custom-elements-bundle/index.ts. Traza cómo las opciones de dist-custom-elements llegan a Rollup y cómo se gestionan las colecciones de Stencil cargadas de forma diferida; se considera terminado cuando se admitan entradas externas de tipo string o RegExp y los componentes lazy solicitados permanezcan externos sin incluirlos en el bundle.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Resolution: Refine
Prerequisites
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:

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

Lenguaje dominante
TypeScript
Estrellas
13.2k
Forks
865
Merge medio
2 d 16 h
PR fusionados (30 d)
29

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de stenciljs/core

Todos los issues de stenciljs/core

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.