Es ist allerdings erforderlich, dass die Quelle, also in diesem Fall „bar.js“, im EMS-Format geschrieben wurde. In der CommonJS-Schreibweise ist es bspw. webpack oder Rollup nicht möglich, auf Basis dieses Formats eine statische Code-Analyse durchzuführen. In der Regel hat man bei eigens erstellen Dateien damit keine Probleme, wenn man dort das EMS-Format verwendet.
Vorsicht bei Dependencies
Es ist anhand des <span class="hljs-keyword">import</span>-Statements nicht zu erkennen, ob die Quelle im EMS-Format geschrieben ist. Hierfür ist ein Blick in die package.json der Dependency notwendig.
Bekannterweise wird die Dependency mit der Datei aufgelöst, die unter dem Feld „main“ steht. Bundler wie webpack oder Rollup halten jedoch zunächst Ausschau nach dem Feld „module“, um eine EMS-Version der Dependency ausfindig zu machen.
Bekannte Dependencies, bei denen der Code nicht im EMS-Format vorliegt, sind:
Je nach Dependency gibt es ggf. Möglichkeiten, wie man dennoch diese Tree-Shaking-freundlich einsetzen kann. Siehe dazu:
Vorsicht auch bei Babel
Wenn wir also durch unsere <span class="hljs-keyword">import</span>-Schreibweise und die Schreibweise der Dependency sichergestellt haben, dass die Bedingungen für Tree Shaking erfüllt sind, kann einem nur noch Babel in die Quere kommen.
Sollte man „babel-preset-env“ verwenden, dann wird es in den Standard-Einstellungen das EMS-Format in CommonJS umwandeln. Um dies zu verhindern, setzt man die Option „modules“ auf <span class="hljs-literal">false</span>.
Zusammenfassung
- Nutze webpack
- Benutze die ES2015-Module-Syntax (
<span class="hljs-keyword">import</span>und<span class="hljs-keyword">export</span>) - Stelle sicher, dass Tools wie Babel bzw. preset-env deinen EMS-Code nicht in CommonJS umwandeln
- Nutze Tools wie Uglify oder Terser über den Production Build von webpack, um das Tree Shaking auch auszuführen