Tengo un proyecto Vue que tiene una configuración de paquete web estándar generada a partir de la CLI de Vue. Esto le da una estructura de directorio del proyecto como:
public\ css\ images\ index.html src\ tests\ package.json etc... Entonces, el directorio de activos estáticos predeterminado es public\ en la raíz del directorio del proyecto. Ahora quiero especificar otro directorio estático (que se ubicará en algún lugar de src\ ) de modo que el contenido de estos dos directorios se fusione en la compilación. En caso de conflictos de archivos, el archivo de src\ debe sobrescribir el de public\ .
¿Cómo puedo hacer esto con webpack?
La razón por la que necesito esto es porque quiero hacer compilaciones separadas para diferentes clientes. Cada cliente tendrá sus propios activos y componentes específicos que planeo colocar en algún lugar de src\ . P.ej:
public\ // shared static assets src\ components\ // shared stuff for all customers store\ ...etc customer1\ // customer1 specific stuff below this level public\ // merge these with shared static assets and overwrite if necessary components\ store\ index.js customer2\ // customer2 specific stuff below this level public\ components\ store\ index.js Entonces, cuando ejecuto npm run build --customer=customer1 , quiero obtener solo cosas compartidas + customer1 en el paquete. Casi resolví esto para los componentes del cliente, la tienda y otras cosas no estáticas a través de la configuración de alias del paquete web y me pregunto cómo puedo hacerlo para los activos estáticos en el directorio public .
No es así como funciona Webpack. Cuando compila su aplicación, lo primero que hace Webpack es escanear su código y crear un árbol de dependencia. En realidad, una dependencia puede ser muchas cosas, pero piense en ellas como sus "archivos importados".
El escaneo comienza en su punto de entrada, generalmente src/index.js y procede recursivamente desde allí. Lo que quiero dejar claro con esto es que solo se agrupan las dependencias "explícitas", cualquier otra cosa se ignorará. En otras palabras, si no importa algo y tiene un cargador específico para eso, ese activo no se incluirá.
Entonces, nuevamente, Webpack no escanea su directorio src , sino que atraviesa su aplicación desde su punto de entrada.
También considere que con una buena configuración (como la que se incluye con la aplicación Create React), casi todos los activos se convertirán en un módulo JS y se fusionarán en fragmentos con una convención de nomenclatura específica para permitir la invalidación de caché. Esto quiere decir que hay poca probabilidad de que haya colisiones de nombres.
Dado su caso, le recomendaría mucho, mucho, mucho, tener un repositorio diferente para cada cliente diferente. Si necesita reutilizar componentes, cree una biblioteca. Si necesita reutilizar activos, optimícelos y alójelos en una CDN. Esperaría problemas de seguridad, mantenibilidad y escalabilidad con su enfoque.
Finalmente, si insiste, un enfoque viable sería tener un complemento personalizado adjunto a esos directorios "estáticos" dentro de su directorio src (puede buscar si ya hay uno disponible; de lo contrario, consulte los complementos personalizados en la documentación de Webpack). aunque no es tan sencillo). Ese complemento básicamente cambiaría la ruta del archivo importado en función de una variable de entorno o una opción aprobada.
Avíseme si estoy pasando por alto algo, pero realmente creo que debería separar los proyectos, incluso si la "base" es la misma.
Como nota final: es probable que su enfoque rompa cualquier análisis estático (olvídese de TypeScript, Flow, JSDocs, autocompletado y sugerencias de IDE, etc.). También estaría rompiendo el paradigma de la programación modular. Esto se aplica especialmente a los componentes. Con otros activos de medios como imágenes, habría menos restricciones, pero aún encontraría problemas. ¿Cómo se ejecutaría su aplicación en modo dev? En el mejor de los casos, encontrará problemas de rendimiento. Puede romper HMR (Reemplazo de módulo en caliente), pruebas de aplicaciones... Me detendré aquí.