Qu'est-ce que Webpack 4 attend d'un paquet avec sideEffects: false

Question

Webpack 4 a ajouté une nouvelle fonctionnalité: il supporte maintenant un sideEffects drapeau dans l' package.json des modules, il est le groupement.

De Webpack 4: publié aujourd'hui

Sur les 30 derniers jours, nous avons travaillé en étroite collaboration avec chacun des cadres pour s'assurer qu'ils sont prêts à soutenir webpack 4 dans leur cli etc. Même populaire de la bibliothèque comme lodash-es, RxJS soutiennent des effets de drapeau, en utilisant leur dernière version, vous verrez instantanée du faisceau diminue la sortie de la boîte.

De Webpack docs

Les "effets secondaires": false flag en grande-module package.json indique que le paquet de modules ont pas d'effets secondaires (à l'évaluation) et n'exposent que des exportations. Cela permet à des outils comme webpack pour optimiser les ré-exportations.

Tandis que le deuxième lien affiche le résultat de l'utilisation du drapeau, il n'a pas d'expliquer clairement ce qui constitue un effet secondaire. ES6 comprend le concept d'effets secondaires pour les modules comme indiqué ici, mais comment est-ce lié à ce Webpack considère les effets secondaires.

Dans le contexte de l' sideEffects drapeau, ce n'est un module de la nécessité d'éviter d'utiliser sideEffects:false , sans questions, ou inversement, ce n'est un module devez faire afin d'utiliser sideEffects:false , sans questions.

Pour être complet, malgré @SeanLarkin solide de réponse ci-dessous, j'aimerais obtenir des éclaircissements sur les points suivants:

1. Évidemment, les effets secondaires signifie quelque chose de particulier dans fp et comprendrait d'enregistrement (console ou ailleurs) et le fait de lancer des erreurs. Je suppose que dans ce contexte, sont parfaitement acceptables?

2. Peut un module contiennent des références circulaires et toujours utiliser sideEffects: false?

3. Est-il possible de vérifier ou d'un module est en mesure de vérifier qu'un module peut - sideEffects: false - delà de essayer de traquer les erreurs causées par une mauvaise utilisation?

4. Existe-il d'autres facteurs qui pourraient empêcher un module d'être en mesure d'utiliser sideEffects: false?

Answer 1

Sean de le webpack Équipe! Je vais faire de mon mieux en lieu et place de notre documentation, toujours en cours, pour répondre à votre question ici!

Selon l'ECMA Module Spec (je ne vais pas essayer et trouver le lien de sorte que vous aurez confiance en moi ici parce qu'il est enterré),

chaque fois qu'un module de re-exportations de l'ensemble des exportations, (peu importe si elle est utilisée ou non), ils doivent être évalués et exécuté dans le cas où l'une de ces exportations a créé un effet de bord avec un autre.

Par exemple, j'ai créé un petit scénario avec une photo pour mieux visualiser le cas:

Dans cette photo, nous voyons trois modules importés dans un fichier unique. Les modules importés sont ensuite ré-exportés à partir de ce module:

Vous pouvez voir ici qu'aucun des re-exportations sont effectuées par d'autres personnes, donc (si webpack a donné un signal), on peut omettre les exportations b et c de même tracé ou utilisé (taille et le temps de construction des avantages de performance).

Toutefois, dans ce cas, nous voyons que les exportations c est "effectuée" par des modifications de l'état parce qu'il est réaffecté à la somme des b et a. Par conséquent, (c'est pourquoi les spécifications des appels pour cela), nous aurions besoin de comprendre à la fois des b et a et de ses dépendances dans le bundle.

Nous avons choisi "effets secondaires: false," comme un moyen pour enregistrer sur les deux temps de compilation et de construire de taille, car cela nous permet d'instantanément prune (explicitement) les exportations que les développeurs/bibliothèque des auteurs savons sont sans effets secondaires (au détriment d'une propriété dans un package.json, ou en 2 ou 3 lignes de config).

Bien que, techniquement, cet exemple est très primitif, lorsque vous commencez à traiter avec des Cadres ou des Bibliothèques de réexportation un tas de modules à un niveau plus élevé pour le Développeur de l'Expérience (Three.js, Angulaire, lodash-es, etc...), les gains de performance sont importants lorsque (si ils sont sideEffect module gratuit export) vous drapeau de cette manière.

Précisions Complémentaires:

1. Évidemment, les effets secondaires signifie quelque chose de particulier dans fp et comprendrait d'enregistrement (console ou ailleurs) et le fait de lancer des erreurs. Je suppose que dans ce contexte, sont parfaitement acceptables?

Dans le cas que c'est en essayant de résoudre, oui. Aussi longtemps que les effets créés à l'encontre de module, les exportations ne sont pas effectués par d'autres et qui serait la cause de la tailler pour ne pas être acceptable.

2. Peut un module contiennent des références circulaires et toujours utiliser sideEffects: false?

Il devrait, en théorie.

3. Est-il possible de vérifier ou d'un module est en mesure d'utiliser sideEffects: false - delà de essayer de traquer les erreurs causées par une mauvaise utilisation?

Pas que je sache, mais ce serait un outil formidable.

4. Existe-il d'autres facteurs qui pourraient empêcher un module d'être en mesure d'utiliser sideEffects: false?

Si la propriété n'est pas en package.json ou définies en module.rulesou mode: production n'est pas défini (qui tire profit de l'optimisation).

Answer 2

Cette sideEffects réglage est très vague et n'est pas décrite de façon suffisante dans les docs. Les docs sont la plupart du temps comme "il y a un sideEffects drapeau pour les modules gratuits de des effets secondaires".

Le consensus est que "n'a pas d'effets secondaires" de la phrase peut être decyphered comme "ne pas parler de choses externe pour le module au plus haut niveau".

Ma compréhension est que c' sideEffects indicateur est uniquement pour les "exportations", une "re-export" en cours:

export { a } from './lib/a'
export { b } from './lib/b'

quelque part en <npm-package>/index.js (ou tout autre fichier à l'intérieur de l' <npm-package>).

Si Webpack détecte que l'application des seules importations en a de <npm-package>, et de ne pas importer b n'importe où, puis Webpack pouvez simplement déposer l' export { b } from './lib/b' ligne de <npm-package>/index.js résultant en n'incluant pas './lib/b.js' le fichier dans le bundle (qui en fait est plus petite par la taille de l' './lib/b.js' le fichier).

Maintenant, si './lib/b.js' a certaines haut niveau de lignes de code en faisant quelques "effets secondaires", c'est à dire si './lib/b.js' a fait quelque chose comme:

• window.jQuery = ...
• if (!global.Set) global.Set = require('babel-polyfill').Set
• new XmlHttpRequest().post('/analytics', data)

ensuite, './lib/b.js' serait dit avoir des "effets secondaires" en raison de son haut niveau de code (qui sera exécuté lors de l' import './lib/b') affecte quelque chose en dehors de la portée de l' './lib/b.js' le fichier.

En même temps, tant que './lib/b.js' de premier niveau de code n'atteint pas à l'extérieur qu' *.js le fichier puis c'est ne pas en avoir "effets secondaires":

let a = 1
a = a + 1 + computeSomeValue()
export default a
export const b = a + 1
export const c = b + 1

ce sont tous pas des "effets secondaires".

Et il y a une dernière chose à corriger: si un package npm a tout *.css fichiers qu'un utilisateur peut - import ces *.css des fichiers sont tous des "effets secondaires", parce que:

import 'npm-package/style.css'

n'a pas de variable assignée à cette import ce qui signifie "ce module importé n'est pas utilisé n'importe où dans l'application" pour Webpack. Et donc Webpack simplement ignore l' 'npm-package/style.css' le fichier à partir de l'ensemble de la partie de l'arbre qui tremble" si l' npm-package a sideEffects: false drapeau. Donc, au lieu d'écrire sideEffects: false toujours écrire "sideEffects": ["*.css"]. Même si votre package npm n'exporte pas de CSS fichiers, il peut le faire dans l'avenir et ceci en garde contre le fameux "fichier CSS pas inclus" bug.