Resolver el problema de que el paquete axios es demasiado grande en el applet taro

antecedentes

Cuando usamos taro y @freud/http(el proyecto interno de la empresa, desarrollo secundario basado en axios), descubrimos que había muchos paquetes inútiles en el producto de compilación, lo que resultó en que el producto aumentara unos 150 kb. Después de algunas búsquedas, descubrí que se debe a que el subprograma taro no puede analizar campos como el módulo del navegador en package.json, y @frued/http necesita admitir entornos web y de subprogramas, y hay un atributo de navegador en axios:

  "browser": {
    "./lib/adapters/http.js": "./lib/adapters/xhr.js"
  },
复制代码

Por lo tanto, cuando axios se introduzca en taro, lib/adapters/http.jstambién se empaquetará Habrá muchos paquetes dependientes, como zlib en http.js, lo que generará el problema de que el paquete anterior sea demasiado grande .

Soluciones

Primero, podemos ubicar la ubicación relacionada con el código fuente de axios:

  if (typeof XMLHttpRequest !== 'undefined') {
    // For browsers use XHR adapter
    adapter = require('./adapters/xhr');
  } else if (typeof process !== 'undefined' && Object.prototype.toString.call(process) === '[object process]') {
    // For node use HTTP adapter
    adapter = require('./adapters/http');
  }
复制代码

En circunstancias normales, en un entorno web, ./lib/adapters/http.jsse ./lib/adapters/xhr.jsreemplazará por lo que el código anterior se convertirá después del empaquetado.

  if (typeof XMLHttpRequest !== 'undefined') {
    // For browsers use XHR adapter
    adapter = require('./adapters/xhr');
  } else if (typeof process !== 'undefined' && Object.prototype.toString.call(process) === '[object process]') {
    // For node use HTTP adapter
    adapter = require('./adapters/xhr');
  }
复制代码

Después de saber cómo debería verse el producto de compilación en circunstancias normales, veamos nuestro producto de compilación actual. Debido a que @frued/http está construido en base al resumen, el producto es el siguiente: Index.js retiene una referencia a axios var axios = require('axios'), mientras que el axios correspondiente lib/default.jsaún se referencia adapter/httpFigura 1 Figura 2

Hasta ahora, tenemos aproximadamente dos direcciones para resolver el problema:

Ajustes y optimizaciones de la herramienta de compilación
Modifique el código fuente para evitar referencias redundantes

plan especifico

Entonces las soluciones correspondientes son:

Cargue axios en la biblioteca privada y elimine las referencias relevantes a http.js
Usando el mecanismo de parche del paquete npm, @freud/httpmodifique el código fuente de axios en , elimine las referencias relevantes a http.js
Dividir en @freud/httppaquetes de 2 npm, correspondientes al entorno web y al entorno de applet respectivamente
Use webpack en su lugar @freud/httppara empaquetar
Introducir complemento acumulativo

1-3 很简单，不用细讲。先讲一讲第四点，为什么使用webpack就可以解决这个问题。 rollup中为了更好地做tree shaking,因此只保留着对依赖的引用，而不是直接将依赖的代码打包到index.js中（见图一）。所以@freud/http 引入axios时，axios的代码依然保留着对http.js的引用，只有到实际web项目运行时，browser字段生效，则http.js被xhr.js替换。但是webpack构建时，会自动解析模块内容，将所有模块打包后的内容和id以key value的形式存在于构建产物的一个数组中，此时http.js就会被xhr.js替换。故由于对依赖包的处理方式不同，webpack构建即可解决此问题。第五点，尚在研究中，有基于rollup做二次封装的构建工具bili 解决了这个问题。

结尾

因为 @freud/http 为monorepo项目，统一使用rollup构建。若所有包都改用webpack构建，则成本太大。基于此，我选择了在subpage中添加webpack做二次构建的方式，即在rollup将@freud项目中的子包构建完之后，再执行@freud/http 中的webpack构建命令，将rollup的构建产物lib/index.js 用webpack再构建一次。这样能够避免在子项目中再写一遍babel配置，做到所有子包的基础构建配置相同。