Utilidad de cobertura de código de Chrome Dev Tools
-
En producción, por supuesto.
-
Aparte del CSS (la primera vez que usé styled-jsx
y necesitará mejorar el diseño de estilos compartidos o usar algo como styletron
), ¿he entendido mal la función de división automática de código?
Para dar un poco de contexto, uso un HOC para envolver cada página, y estoy pasando métodos y accesorios que no necesariamente se usan en cada página. Además: puede que haya sido descuidado aquí y allá con algunas importaciones; Utilizo re-base, que actualmente importa todo Firebase (no es necesario en mi caso de uso).
¿Estoy posiblemente mezclando automatic code splitting
del paquete web con static analysis and tree shaking
a là rollup? Si es así,
¿Debería Next realizar la eliminación de códigos muertos y sacudidas de árboles?
Si no es así, ¿tiene alguna sugerencia sobre cómo abordar y resolver este problema? Los resultados de la cobertura de Chrome Dev Tools no se pueden exportar trivialmente por el momento y, por lo tanto, no estoy seguro de cómo identificar las rutas de código no utilizadas y las importaciones con la salida minificada.
¿Sería posible y tendría sentido usar algo como webpack-rollup-loader ?
¿Puede algo de esto conducir a mejoras en la ya asombrosa forma en que funciona Next?
¡Gracias!
Supongo que esto se debe a la forma en que webpack maneja la agitación de árboles.
Necesita módulos ES2015. Espero que React no proporcione eso y por eso es así.
Pero me gustaría experimentar aquí. Cualquier idea / mejora es bienvenida.
¿Posiblemente relacionado con el paquete web # 2867 ?
Vinculado desde ese hilo, aquí hay aparentemente una utilidad para probar si el temblor de árboles ocurre correctamente en Webpack:
https://github.com/halt-hammerzeit/es6-tree-shaking-test
Comentario más útil
Vinculado desde ese hilo, aquí hay aparentemente una utilidad para probar si el temblor de árboles ocurre correctamente en Webpack:
https://github.com/halt-hammerzeit/es6-tree-shaking-test