Comment créer plusieurs chemins de sortie dans la configuration Webpack


165

Quelqu'un sait-il comment créer plusieurs chemins de sortie dans un fichier webpack.config.js? J'utilise bootstrap-sass qui est livré avec quelques fichiers de polices différents, etc. Pour que webpack les traite, j'ai inclus un chargeur de fichiers qui fonctionne correctement, mais les fichiers qu'il génère sont enregistrés dans le chemin de sortie spécifié pour le reste de mes fichiers:

    output: {
      path: __dirname + "/js",
      filename: "scripts.min.js"
    }

J'aimerais réaliser quelque chose où je pourrais peut-être regarder les types d'extensions pour n'importe quel webpack en sortie et pour les choses se terminant par .woff .eot, etc., les faire détourner vers un chemin de sortie différent. Est-ce possible?

J'ai fait un peu de recherche sur Google et suis tombé sur ce * problème sur github où quelques solutions sont proposées, éditez:

mais il semble que vous ayez besoin de connaître le point d'entrée pour pouvoir spécifier une sortie en utilisant la méthode de hachage, par exemple:

var entryPointsPathPrefix = './src/javascripts/pages';
var WebpackConfig = {
  entry : {
    a: entryPointsPathPrefix + '/a.jsx',
    b: entryPointsPathPrefix + '/b.jsx',
    c: entryPointsPathPrefix + '/c.jsx',
    d: entryPointsPathPrefix + '/d.jsx'
  },

  // send to distribution
  output: {
    path: './dist/js',
    filename: '[name].js'
  }
}

* https://github.com/webpack/webpack/issues/1189

Cependant, dans mon cas, en ce qui concerne les fichiers de polices, le processus d'entrée est en quelque sorte abstrait et tout ce que je sais, c'est la sortie. dans le cas de mes autres fichiers subissant des transformations, il y a un point connu où je demande qu'ils soient ensuite traités par mes chargeurs. s'il y avait un moyen de savoir où se déroulait cette étape, je pourrais alors utiliser la méthode de hachage pour personnaliser les chemins de sortie, mais je ne sais pas où ces fichiers sont requis.

Réponses:


221

Je ne sais pas si nous avons le même problème puisque webpack ne prend en charge qu'une seule sortie par configuration à partir de juin 2016. Je suppose que vous avez déjà vu le problème sur Github .

Mais je sépare le chemin de sortie en utilisant le multi-compilateur . (c'est-à-dire séparer l'objet de configuration de webpack.config.js).

var config = {
    // TODO: Add common Configuration
    module: {},
};

var fooConfig = Object.assign({}, config, {
    name: "a",
    entry: "./a/app",
    output: {
       path: "./a",
       filename: "bundle.js"
    },
});
var barConfig = Object.assign({}, config,{
    name: "b",
    entry: "./b/app",
    output: {
       path: "./b",
       filename: "bundle.js"
    },
});

// Return Array of Configurations
module.exports = [
    fooConfig, barConfig,       
];

Si vous avez une configuration commune parmi eux, vous pouvez utiliser la bibliothèque d' extension ou Object.assigndans ES6 ou l' {...}opérateur de propagation dans ES7.


Je n'ai pas exécuté l'extrait de code, une erreur ou une faute de frappe peut se produire
Yeo

J'ai fait tourner votre extrait, ça marche comme du charme ... Surpris que personne ne l'ait repéré, hein développeurs frontend, pas de patience, toujours pressé ;-). J'exporte les configurations de la même manière, mais ma déclaration est différente / standard: var config = {entry: SOURCE_DIR + '/index.jsx', ....} Je n'ai pas non plus utilisé de compilateur multiple: - \
Aubergine

Ou vous pouvez simplement faire un webpack && cp etc dans npm?
SuperUberDuper

1
C'est très utile pour moi de déployer un package npm à la fois dans le dossier d'origine (les tests automatiques sont là) mais aussi dans le dossier de l'application qui implémente le package. De cette façon, je peux ignorer l'étape de téléchargement de npm et tester en direct mon code de package mis à jour jusqu'à ce que la nouvelle version soit stable et prête à être publiée sur npm.
Adrian Moisa

<pre> <code> var config = {// TODO: Ajouter un module de configuration commun: {},}; </code> </pre> L' module{}objet est incorrect. Ce n'est pas obligatoire. Il sera étendu / fusionné au même niveau que les mots clés name, entry,output ( à partir de votre exemple). <pre> <code> {module: {mode: "development", devtool: "source-map"}}, nom: "a", entrée: "./a/app", sortie: {chemin: "/ a ", nom de fichier:" bundle.js "}} </code> </pre>
Rob Waa

249

Webpack prend en charge plusieurs chemins de sortie.

Définissez les chemins de sortie comme clé d'entrée. Et utilisez le namecomme modèle de sortie.

configuration webpack:

entry: {
    'module/a/index': 'module/a/index.js',
    'module/b/index': 'module/b/index.js',
},
output: {
    path: path.resolve(__dirname, 'dist'),
    filename: '[name].js'
}

généré:

└── module
    ├── a
    │   └── index.js
    └── b
        └── index.js

4
Dans mon cas, je veux qu'une sortie ne contienne pas de chunkhash, y a-t-il une solution simple à cela? Merci.
raRaRa

1
@zhengkenghong Je crois que le chemin de sortie généré en aurait besoin dist. Donc, au lieu d' module/a/index.jsêtre un chemin de sortie, cela devrait être module/a/dist/index.jsOu bien, vous écrasez vos fichiers d'entrée.
dance2die

1
Le distdossier @Sung est déjà configuré dans le chemin de sortie. Donc le fichier généré serait en fait dist/module/a/index.js, ce que je n'ai pas mentionné.
zhengkenghong

4
Je pense que cela devrait être la réponse acceptée car c'est la réponse de la documentation Webpack 4. -> webpack.js.org/concepts/output/#multiple-entry-points
Sera le

1
@raRaRa En retard à la fête, mais vous pouvez le faire en utilisant une fonction pour output.filenamecomme documenté ici: webpack.js.org/configuration/output/#outputfilename
Thomas

22

Si vous pouvez vivre avec plusieurs chemins de sortie ayant le même niveau de profondeur et la même structure de dossiers, il existe un moyen de le faire dans webpack 2 (vous n'avez pas encore testé avec webpack 1.x)

En gros, vous ne suivez pas les règles de la doc et vous fournissez un chemin pour le nom de fichier.

module.exports = {
    entry: {
      foo: 'foo.js',
      bar: 'bar.js'
    },

    output: {
      path: path.join(__dirname, 'components'),
      filename: '[name]/dist/[name].bundle.js', // Hacky way to force webpack   to have multiple output folders vs multiple files per one path
    }
};

Cela prendra cette structure de dossier

/-
  foo.js
  bar.js

Et transformez-le en

/-
  foo.js
  bar.js
  components/foo/dist/foo.js
  components/bar/dist/bar.js

@ccnixon il est documenté ici webpack.js.org/configuration/output/#outputfilename recherche pour "encore autorisé".
John Henckel

3

J'ai écrit un plugin qui peut, espérons-le, faire ce que vous voulez, vous pouvez spécifier des points d'entrée connus ou inconnus (en utilisant glob ) et spécifier des sorties exactes ou les générer dynamiquement en utilisant le chemin et le nom du fichier d'entrée. https://www.npmjs.com/package/webpack-entry-plus


3

Vous pouvez certainement renvoyer un tableau de configurations à partir de votre fichier webpack.config. Mais ce n'est pas une solution optimale si vous voulez simplement qu'une copie des artefacts se trouve dans le dossier de la documentation de votre projet, car cela permet à Webpack de créer votre code en doublant le temps total de construction.

Dans ce cas, je recommanderais d'utiliser le plugin FileManagerWebpackPlugin à la place:

const FileManagerPlugin = require('filemanager-webpack-plugin');
// ...
plugins: [
    // ...
    new FileManagerPlugin({
      onEnd: {
        copy: [{
          source: './dist/*.*',
          destination: './public/',
        }],
      },
    }),
],

1

Vous ne pouvez avoir qu'un seul chemin de sortie.

à partir de la documentation https://github.com/webpack/docs/wiki/configuration#output

Options affectant la sortie de la compilation. les options de sortie indiquent à Webpack comment écrire les fichiers compilés sur le disque. Notez que s'il peut y avoir plusieurs points d'entrée, une seule configuration de sortie est spécifiée.

Si vous utilisez un hachage ([hash] ou [chunkhash]), assurez-vous d'avoir un ordre cohérent des modules. Utilisez OccurenceOrderPlugin ou recordsPath.


Merci. Je vais laisser le Q juste au cas où quelqu'un pourrait trouver une solution de contournement.
spb

quel est votre cas d'utilisation pour exiger 2 chemins de sortie? Il semble que vous vouliez 2 applications ou 1 application et 1 module.
ex-zac-

Je pensais que j'en avais besoin d'un qui était dédié à la sortie générée par le chargeur de fichiers qui allait tous à la racine du projet alors que je le voulais dans son propre dossier. J'ai fini par rediriger le chemin de sortie dans le chargeur lui-même selon ma réponse ci-dessous.
spb

1
Ce n'est pas tout à fait vrai. Vous ne pouvez techniquement spécifier qu'un seul chemin de sortie, mais il s'appliquera pour chaque clé dans un objet d'entrée, vous permettant d'avoir plusieurs sorties - webpack.js.org/concepts/entry-points
sanjsanj

0

En fait, je me suis contenté d'aller dans index.js dans le module de chargement de fichiers et de changer l'endroit où le contenu était émis. Ce n'est probablement pas la solution optimale, mais jusqu'à ce qu'il y ait un autre moyen, cela me convient car je sais exactement ce qui est géré par ce chargeur, qui n'est que des polices.

//index.js
var loaderUtils = require("loader-utils");
module.exports = function(content) {
    this.cacheable && this.cacheable();
    if(!this.emitFile) throw new Error("emitFile is required from module system");
    var query = loaderUtils.parseQuery(this.query);
    var url = loaderUtils.interpolateName(this, query.name || "[hash].[ext]", {
        context: query.context || this.options.context,
        content: content,
        regExp: query.regExp
    });
    this.emitFile("fonts/"+ url, content);//changed path to emit contents to "fonts" folder rather than project root
    return "module.exports = __webpack_public_path__ + " + JSON.stringify( url) + ";";
}
module.exports.raw = true;

1
Je ne sais pas si c'est toujours un problème pour vous, mais jetez un œil à npmjs.com/package/webpack-entry-plus
sanjsanj
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.