Explicaciones preliminares sobre la biblioteca de materias

Siento haberte tomado el tiempo haciéndote leer esto. Lo escribí para responder preguntas como "¿Qué estás haciendo?" y "¿Por qué haces esto?".

La biblioteca consta de un gran número de funciones auxiliares y clases. En este sentido, es similar a lodash ( verifique la estructura de lodash ), pero a diferencia de lodash, el código fuente ha sido organizado por directorios multinivel . Es cómodo para los desarrolladores pero podría no serlo para los usuarios: para importar la función deseada al proyecto, el usuario debe saber dónde está, por ejemplo:

 import { computeFirstItemNumberForSpecificPaginationPage } from "@yamato-daiwa/es-extensions/Number/Pagination";

Para resolver este problema, la mayoría de las funciones se importaron a index.ts y se exportaron nuevamente desde allí. Ahora el usuario puede obtener la función deseada como:

 import { computeFirstItemNumberForSpecificPaginationPage } from "@yamato-daiwa/es-extensions";

Tenga en cuenta que todas las funciones en index.ts (serán compiladas por TypeScript a index.js ) están diseñadas para BrowserJS y NodeJS. La funcionalidad especialmente para BrowserJS está en BrowserJS.ts y especialmente para NodeJS en NodeJS.ts (actualmente está casi vacío pero la metodología de reexportación es la misma).

Además, hasta que se resuelva este problema, incluí el JavaScript compilado en el repositorio de la biblioteca ( directorio Distributable ).

Problema

A partir de ahora, @yamato-daiwa/es-extensions es la biblioteca y cualquier proyecto que dependa de ella es el proyecto consumidor .

Esperaba que todas las funciones/clases no utilizadas del proyecto consumidor fueran eliminadas por las optimizaciones de Webpack . Por ejemplo, en el caso siguiente, esperaba que la función isUndefined solo se dejara en el paquete Webpack:

 import { isUndefined } from "@yamato-daiwa/es-extensions" const test: string | undefined = "ALPHA"; console.log(isUndefined(test));

Pero en realidad, Webpack dejó TODO desde index.js de la biblioteca. Embellecí el JavaScript minimizado creado por Webpack; es como:

 (() => { "use strict"; var e = { 5272: (e, t) => { Object.defineProperty(t, "__esModule", { value: !0 }), t.default = function(e, t) { for (const [a, n] of e.entries()) if (t(n)) return a; return null } }, 7684: (e, t) => { Object.defineProperty(t, "__esModule", { value: !0 }), t.default = function(e, t) { const a = []; return e.forEach(((e, n) => { t(e) && a.push(n) })), a } }, // ...

Supongo que todos entienden que eso no es aceptable, especialmente para las aplicaciones de navegador donde cada kilobyte cuenta.

¿Cómo resolver este problema? La solución ideal (si existe) no tocará la organización de los archivos fuente, solo cambie la configuración de TypeScript.

reproducción

Creé un repositorio más (repro) donde puedes probar el ejemplo anterior.

Flujo del experimento

1. Obtener este repositorio por VCS
2. Instale las dependencias como siempre (comando npm i ).
3. Compruebe el src/index.ts . Importa la función isUndefined de la biblioteca y la usa.
4. Ejecutar npm run ProductionBuild
5. Embellece la salida index.js con una herramienta como beautifier.io . Verá que se ha agrupado toda la biblioteca, mientras que se desea que solo se haya agrupado inUndefined .

Reflexiones sobre la causa

El primer candidato a causa es el uso del patrón de reexportación, exactamente Source/index.ts , Source/BrowserJS.ts y Source/NodeJS . El index.js compilado se ve así:

 const isStringifiedNonNegativeIntegerOfRegularNotation_1 = require("./Numbers/isStringifiedNonNegativeIntegerOfRegularNotation"); exports.isStringifiedNonNegativeIntegerOfRegularNotation = isStringifiedNonNegativeIntegerOfRegularNotation_1.default; const separateEach3DigitsGroupWithComma_1 = require("./Numbers/separateEach3DigitsGroupWithComma"); exports.separateEach3DigitsGroupWithComma = separateEach3DigitsGroupWithComma_1.default;

( Consultar expediente completo )

Si para importar cada función desde su módulo individual, como import isUndefined from "@yamato-daiwa/es-extensions/TypeGuards/isUndefined" en lugar de import { isUndefined } from "@yamato-daiwa/es-extensions" , no se generará ningún código redundante. producción. Pero como ya dije, esta solución es inaceptable porque los usuarios de la biblioteca deben saber dónde isUndefined y se han organizado otras funciones.

La otra causa podría ser el tipo de módulos de salida. Actualmente es un CommonJS . Aquí está el tsconfig.json de la biblioteca:

 { "compilerOptions": { "target": "ES2020", "module": "CommonJS", "moduleResolution": "Node", "strict": true, "noUnusedLocals": true, "noUnusedParameters": true, "noImplicitReturns": true, "removeComments": true, "outDir": "Distributable/", "declaration": true }, "include": [ "Source/**/*" ] }

Según la hipótesis, según el tipo de módulo específico, Webpack podría agrupar el código en una estructura monolítica en la que es imposible descomponer y filtrar algunos módulos, incluso si no se han utilizado.

Ahora todos estos (AMD, UMD, CommonJS) se convierten lentamente en parte de la historia, pero aún podemos encontrarlos en scripts antiguos.

🌎 javascript.info

Por cierto, la configuración de TypeScript en el proyecto de consumo también podría afectar (incluido en la reproducción). Actualmente es:

 { "compilerOptions": { "target": "ES2020", "strict": true, "moduleResolution": "node", "allowSyntheticDefaultImports": true, "experimentalDecorators": true, "skipLibCheck": true, "baseUrl": "./", "paths": { "@SourceFilesRoot/*": ["./src/*"] } } }