2017-09-15 4 views
4

J'ai un build webpack à plusieurs entrées et je travaille sur l'optimisation de la taille des artefacts pour la production. webpack-bundle-analyzer produit l'image suivante:Pourquoi la dépendance est-elle répétée plusieurs fois dans l'artefact Webpack?

enter image description here

Il est évident que les AtlasKit dépendances constituent un énorme morceau de la taille d'artefact totale. Plus précisément, je vois que styled-components.es.js est répété plusieurs fois. Plus encore, cette même dépendance est également présente dans vendor.js qui est elle-même partagée par tous les autres paquets.

Quelqu'un peut-il expliquer pourquoi styled-components.es.js est répété partout et pourquoi il ne peut pas être partagé par une seule dépendance dans vendor.js? Y at-il quelque chose que je peux faire pour supprimer les doublons et ne dépend que de la dépendance styled-components.es.js unique dans vendor.js?

J'ai trouvé un peu étrange que les dépendances AtlasKit aient un dossier node_modules imbriqué inclus dans le package. Pourquoi dist ne suffit pas? Peut-être que cela fait partie de la raison pour laquelle styled-components.es.js ne peut pas être partagée via vendor.js?

enter image description here

J'ai essayé d'exclure la dépendance manuellement via IgnorePlugin de webpack (similaire à moment.js locales), mais a échoué jusqu'à présent de le faire.

Toute idée serait grandement appréciée. Merci!

+0

Avez-vous déjà trouvé une solution pour cela?Avoir le même problème, pensé que j'étais juste mauvais au webpack mais il semble que quelque chose est étrangement configuré avec @atlaskit –

+0

@MitchLillie malheureusement je n'ai pas et j'ai arrêté d'investir plus de temps à ce sujet. Cependant, si jamais je trouve un peu de temps, j'aimerais approfondir cette question. Je crois toujours qu'il devrait y avoir une solution. – tobi

Répondre

1

Il semble que vous souhaitiez consolider une dépendance à partir de plusieurs blocs en un bloc commun: Pour cela, je recommande d'examiner webpack.CommonsChunkPlugin.

un intérêt particulier est la propriété minChunks vous pouvez passer au plug-in:

minChunks: Numéro | Infinity | fonction (module, compte) -> booléen, // Le nombre minimum de morceaux qui ont besoin contenir un module avant qu'il ne soit déplacé dans le bloc des communs. // Le nombre doit être supérieur ou égal à 2 et inférieur ou égal au nombre de blocs. // Le passage Infinity crée simplement le bloc des communs, mais n'y déplace aucun module. // En fournissant un function, vous pouvez ajouter une logique personnalisée. (Par défaut, le nombre de morceaux)

Je vous conseille d'essayer d'ajouter ce plugin à votre config Webpack:

new webpack.optimize.CommonsChunkPlugin({ 
    children: true, 
    async: true, 
    minChunks: 3 
}) 

Cette utilisation est décrite plus loin dans "Extra async commons chunk".

Si vous souhaitez voir la quantité de code partagée entre vos blocs, essayez également samccone/bundle-buddy pour Webpack.

Si vous utilisez déjà CommonsChunkPlugin, je devrais voir votre config Webpack pour fournir plus d'informations.

+0

Salut Peter, merci pour votre réponse. J'utilise déjà CommonsChunkPlugin, c'est comme ça que j'obtiens 'vendor.js'. Vous pouvez voir ma config Webpack ici: https://pastebin.com/vgiQrPqs – tobi

+0

Merci d'avoir posté votre config. Je soupçonne que vous n'obtenez pas vraiment de «tree-shaking» sur @ atlaskit parce que vous importez le code déjà transpilé. Il ne semble pas que '@ atlaskit' prenne en charge le champ' 'module '' qui vous permettrait de le consommer en tant que module ES. Atlassian Kit semble livré avec une clé '" ak: webpack: raw ":" src/index.jsx "' qui pointe vers leur code source brut. Vous pouvez inclure à partir de ce point d'entrée en utilisant un processus décrit dans ['ce poste 2ality] (http://2ality.com/2017/06/pkg-esnext.html#package-users). Ils devraient utiliser le champ "module", pas 'ak: webpack: raw' – Peter