44 votes

Comment puis-je créer deux bundles distincts avec vue-cli 3?

Je veux construire deux applications Vue distinctes qui seront servies sur deux routes différentes dans une application Express : une application Vue 'public' et une application Vue 'admin'. Ces deux applications ont leur propre routeur et magasin, mais elles partagent beaucoup de composants personnalisés. Comment puis-je modifier le modèle webpack par défaut pour qu'il produise deux bundles distincts en fonction de mes deux points d'entrée différents ('public' et 'admin') ? L'objectif serait d'obtenir une configuration plus ou moins comme celle-ci :

my-app/
+- ...
+- dist/
|  +- admin/         Bundle et fichiers Admin
|  +- public/        Bundle et fichiers Public
+- src/
|  +- components/    Composants partagés
|  +- admin/         Point d'entrée, routeur, magasin... pour l'application admin
|  +- public/        Point d'entrée, routeur, magasin... pour l'application public
+- ...

Doit être disponible 2 serveurs de développement http://localhost:8080/admin et http://localhost:8080/public Chaque projet doit être dans son propre dossier dans dist, et son propre public

Ce que j'ai aujourd'hui : créé le fichier vue.config.js dans le répertoire racine Avec :

module.exports = {
  // ajuster la configuration webpack interne.
  // voir https://github.com/vuejs/vue-cli/blob/dev/docs/webpack.md
  chainWebpack: config => {
    // Si vous souhaitez supprimer le point d'entrée standard
    config.entryPoints.delete('app')

    // puis ajoutez les vôtres
    config.entry('admin')
      .add('./src/admin/index.js')
      .end()
    .entry('public')
      .add('./src/public/index.js')
      .end()
  }
}

0 votes

Avez-vous obtenu une solution pour cela?

31voto

Kamal Khan Points 161

En supposant que vous ayez besoin de builds complètement séparées, avec quelques scripts partagés guidés par vos entrées, vous pouvez ajouter des commandes de build séparées.

Dans la section "scripts" de votre package.json :

"scripts": {
    "build:admin": "vue-cli-service build --dest dist/admin src/admin/index.js,
    "build:public": "vue-cli-service build --dest dist/public src/public/index.js
}

Pour les builds admin, vous pouvez exécuter :

npm run build:admin

et pour les builds public :

npm run build:public

Pour plus d'informations, consultez la documentation sur les cibles de build.

1 votes

Cela est très utile lorsqu'il est utilisé avec pages de vue-cli 3 pour maintenir votre répertoire de sortie des pages complètement séparé.

3 votes

Lorsque vous utilisez vue-cli-service, il est bon d'utiliser --no-clean, sinon le répertoire dist est supprimé à chaque construction.

0 votes

Faites attention que si vous suivez cette approche et que vous essayez de conserver des fichiers que seul l'administrateur requiert (par exemple Vuetify), vous constaterez que le dossier public contiendra également le JS/CSS de Vuetify dans le bundle. La solution consiste à avoir 2 fichiers vue.config.js distincts, l'un avec la section index de stackoverflow.com/a/50820261/908677 et un autre avec la section administrateur. Ensuite, vous aurez une séparation complète lors de la construction des applications compilées. La chose étrange est que lorsque vous utilisez "npm run serve", un seul fichier vue.config.js fonctionne très bien sans causer de fuites de bibliothèques de fournisseurs réservées à l'administration dans l'autre.

22voto

Lucile Fievet Points 196

Je suis également très intéressé par cette question.

Peut-être que nous pouvons résoudre ce problème avec des sous-pages :

https://cli.vuejs.org/config/#pages : "Construisez l'application en mode multi-pages. Chaque "page" doit avoir un fichier d'entrée JavaScript correspondant. La valeur doit être un objet où la clé est le nom de l'entrée, et la valeur est soit:"

module.exports = {
  pages: {
    index: {
      // entrée pour la page *publique*
      entry: 'src/index/main.js',
      // le template source
      template: 'public/index.html',
      // sortie en tant que dist/index.html
      filename: 'index.html'
    },
    // une sous-page administrateur 
    // lors de l'utilisation du format de chaîne d'entrée uniquement,
    // le modèle est déduit être `public/subpage.html`
    // et tombe en arrière sur `public/index.html` si non trouvé.
    // Le nom de fichier de sortie est déduit être `admin.html`.
    admin: 'src/admin/main.js'
  }
}

4voto

Boris Serebrov Points 4790

Il est également possible d'avoir plusieurs configurations vue.config.js et de les basculer en utilisant la variable d'environnement VUE_CLI_SERVICE_CONFIG_PATH.

Par exemple, nous pouvons avoir un vue.config.js par défaut et un autre vue.public.config.js que nous pouvons utiliser pour la construction comme ceci:

# Construction en utilisant vue.config.public.js
# Remarque : utiliser le chemin réel ici, cela n'a pas fonctionné avec un chemin relatif
CONF=`realpath vue.config.public.js`
VUE_CLI_SERVICE_CONFIG_PATH=$CONF npm run build

# Construction en utilisant vue.config.js par défaut
npm run build

npm run build est défini dans package.json comme vue-cli-service build:

"scripts": {
    "build": "vue-cli-service build"
}

Remarque : Je n'ai trouvé aucune mention de VUE_CLI_SERVICE_CONFIG_PATH dans la documentation, je l'ai trouvée en regardant le code source.

4voto

Edward Millen Points 99

En s'appuyant sur les autres réponses ici, j'ai trouvé qu'il était possible de spécifier le répertoire de sortie de la construction dans vue.config.js plutôt que de le faire en ligne de commande. En combinant cela avec l'utilisation de la variable d'environnement VUE_CLI_SERVICE_CONFIG_PATH, les choses deviennent beaucoup plus simples - pas besoin de copier/supprimer les fichiers de configuration à chaque construction.

Vous devez spécifier les chemins complets vers les fichiers de configuration de Vue. Cela fonctionne même sur Windows, mais seulement à partir d'un terminal de type Linux (par exemple, je l'ai testé à partir de Git Bash installé par Git pour Windows et ça a bien fonctionné, mais ça ne fonctionne pas à partir de l'invite de commandes Windows normale, car je n'ai pas trouvé de moyen de définir la variable d'environnement dans le script npm qui fonctionnait lorsqu'il était exécuté à partir de là).

https://gist.github.com/EdwardMillen/0c417747cd8ce64b8ba550bdfa582cf5

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X