Open worldzhao opened 3 years ago
大佬呀
大佬呀
嘿嘿,喜欢可以给博客来个 star 哈
我有个问题,如果我用纯js写的使用react 的propTypes类型检查,并且使用webpack打包,这样在组件库引用的时候会有类型提示吗?
js工程化好难理解
我有个问题,如果我用纯js写的使用react 的propTypes类型检查,并且使用webpack打包,这样在组件库引用的时候会有类型提示吗?
这样的话应该没有类型提示了,可以试一下
膜拜大佬,不过有些点还没能理解,整理下请教大佬
膜拜大佬,不过有些点还没能理解,整理下请教大佬
好呀好呀,如果有帮助可以给个 star 哈
貌似不用安装@babel/runtime只使用@babel/plugin-transform-runtime页可以进行helpers抽离,https://github.com/babel/babel/issues/10271
有个疑问, 组件库提供commonjs版本的作用是什么?
默认不是加载我们提供的 es 版本的吗
有个疑问, 组件库提供commonjs版本的作用是什么?
默认不是加载我们提供的 es 版本的吗
从现在的发展来看 cjs 版本的组件的确意义不大,但是考虑历史因素,比如对 es 模块兼容性较差的环境就有意义了,如服务端渲染
大佬你好!这篇文章真的给了我很多启发!个人有两个问题想请教一下。
一个是”为什么组件不能自己去import './index.less'呢?“,这个是我一直有的一个疑问,就是为什么组件JS里不直接引入样式文件,这样外部就不用考虑CSS的按需加载了。这里是不是有这样一个原因呢,就是引入less还是CSS是由项目开发者来定的,如果需要定制主题,那么就需要less,否则用CSS(主题都是写死的)就够了。但是这个在组件库的组件代码里无法确定,所以将样式的引入逻辑单独抽离了。
第二个问题是,我想基于 Antd 组件库来封装一套符合自己公司设计规范的组件库(需要修改 Antd 的主题和一些组件的默认样式)。我的想法是将 Antd 代码作为依赖引入,但是在打包的时候将 Antd 里的 less 文件中的主题变量替换然后输出为 CSS,同时各个组件的JS代码里直接引入CSS文件(外部就不需要做CSS的按需引入了),最后一起打包进来。在进行实现的时候我发现使用 rollup 这类模块打包工具并不适合,我更需要的是对代码进行定制化的编译和输出,所以也打算用 glup 来尝试一下。然后想问下大佬,我的这个想法的方向对不对,因为我没有看到社区里基于 Antd 来开发组件库是这样做的😭,我这个需要将node_modules的 Antd 源码编译一下然后打包进来,看到有些方案是直接基于 Antd 的项目源码来做,或者只将 Antd 作为依赖。
大佬你好!这篇文章真的给了我很多启发!个人有两个问题想请教一下。
- 一个是”为什么组件不能自己去import './index.less'呢?“,这个是我一直有的一个疑问,就是为什么组件JS里不直接引入样式文件,这样外部就不用考虑CSS的按需加载了。这里是不是有这样一个原因呢,就是引入less还是CSS是由项目开发者来定的,如果需要定制主题,那么就需要less,否则用CSS(主题都是写死的)就够了。但是这个在组件库的组件代码里无法确定,所以将样式的引入逻辑单独抽离了。
- 第二个问题是,我想基于 Antd 组件库来封装一套符合自己公司设计规范的组件库(需要修改 Antd 的主题和一些组件的默认样式)。我的想法是将 Antd 代码作为依赖引入,但是在打包的时候将 Antd 里的 less 文件中的主题变量替换然后输出为 CSS,同时各个组件的JS代码里直接引入CSS文件(外部就不需要做CSS的按需引入了),最后一起打包进来。在进行实现的时候我发现使用 rollup 这类模块打包工具并不适合,我更需要的是对代码进行定制化的编译和输出,所以也打算用 glup 来尝试一下。然后想问下大佬,我的这个想法的方向对不对,因为我没有看到社区里基于 Antd 来开发组件库是这样做的😭,我这个需要将node_modules的 Antd 源码编译一下然后打包进来,看到有些方案是直接基于 Antd 的项目源码来做,或者只将 Antd 作为依赖。
第一点是正确的,变量覆盖更换主题是有必要直接使用 less 的,直接引入 less 也可以,只要接入方接受就可以了。其实 css vars 也能做到,不一定要 less。
第二点不需要打包,做编译就可以,你的思路是正确的,npm 包基本上都不是很需要打包,要做的只是编译构建。
所以把 antd 作为 deps 或者 peerDeps 都可以,取决于你想整体做 antd 的上层还是做 antd 的扩展层,至于 antd 的主题定制我没有研究过,反正最后一般都是输出变量 或者 css vars,像 arco 和 semi 都是如此,主题因素不应该对组件库的构建产生影响,需要具体问题具体分析了,你的组件库只是封装了一层,不应该影响 antd 自身的主题应用。
大佬你好!这篇文章真的给了我很多启发!个人有两个问题想请教一下。
- 一个是”为什么组件不能自己去import './index.less'呢?“,这个是我一直有的一个疑问,就是为什么组件JS里不直接引入样式文件,这样外部就不用考虑CSS的按需加载了。这里是不是有这样一个原因呢,就是引入less还是CSS是由项目开发者来定的,如果需要定制主题,那么就需要less,否则用CSS(主题都是写死的)就够了。但是这个在组件库的组件代码里无法确定,所以将样式的引入逻辑单独抽离了。
- 第二个问题是,我想基于 Antd 组件库来封装一套符合自己公司设计规范的组件库(需要修改 Antd 的主题和一些组件的默认样式)。我的想法是将 Antd 代码作为依赖引入,但是在打包的时候将 Antd 里的 less 文件中的主题变量替换然后输出为 CSS,同时各个组件的JS代码里直接引入CSS文件(外部就不需要做CSS的按需引入了),最后一起打包进来。在进行实现的时候我发现使用 rollup 这类模块打包工具并不适合,我更需要的是对代码进行定制化的编译和输出,所以也打算用 glup 来尝试一下。然后想问下大佬,我的这个想法的方向对不对,因为我没有看到社区里基于 Antd 来开发组件库是这样做的😭,我这个需要将node_modules的 Antd 源码编译一下然后打包进来,看到有些方案是直接基于 Antd 的项目源码来做,或者只将 Antd 作为依赖。
第一点是正确的,变量覆盖更换主题是有必要直接使用 less 的,直接引入 less 也可以,只要接入方接受就可以了。其实 css vars 也能做到,不一定要 less。
第二点不需要打包,做编译就可以,你的思路是正确的,npm 包基本上都不是很需要打包,要做的只是编译构建。
所以把 antd 作为 deps 或者 peerDeps 都可以,取决于你想整体做 antd 的上层还是做 antd 的扩展层,至于 antd 的主题定制我没有研究过,反正最后一般都是输出变量 或者 css vars,像 arco 和 semi 都是如此,主题因素不应该对组件库的构建产生影响,需要具体问题具体分析了,你的组件库只是封装了一层,不应该影响 antd 自身的主题应用。
好的,感谢😁
你好,请教下如何在demo代码中,比如
import { Alert } from 'tommy';
实现按需加载呢,尝试了一些方法都没成功,
我看你的代码中目前是手动相对路径引入的样式
你好,请教下如何在demo代码中,比如
import { Alert } from 'tommy';
实现按需加载呢,尝试了一些方法都没成功, 我看你的代码中目前是手动相对路径引入的样式
主要思路就是配置 webpack 的 alias 和 tsconfig 的 path 保证能够正确编译和 ts 提示就可以了,换成 dumi 后没折腾出来,这是 dumi 的对应配置文档,可以尝试一下:https://d.umijs.org/zh-CN/guide/faq#%E5%BC%80%E5%8F%91%E9%98%B6%E6%AE%B5%E5%A6%82%E4%BD%95%E9%85%8D%E7%BD%AE-md-%E6%96%87%E4%BB%B6%E4%B8%AD%E7%9A%84%E6%A0%B7%E5%BC%8F%E6%8C%89%E9%9C%80%E5%BC%95%E5%85%A5
非常感谢,成功了,下来再研究下它的实现。贴一下配置(目录结构和官网稍微有点区别)
export default defineConfig({
title: 'Tommy UI',
mode: 'site',
outputPath: 'doc-site',
exportStatic: {},
dynamicImport: {},
base,
publicPath,
extraBabelPlugins: [
[
'import',
{
libraryName: 'tommy-ui',
camel2DashComponentName: false,
customStyleName: () => {
return `../style/index.less`;
},
},
'tommy-ui',
],
]
});
Found 2 errors in 2 files.
Errors Files 1 node_modules/@types/react-router-config/index.d.ts:12 1 node_modules/@types/react-router-dom/index.d.ts:14 error Command failed with exit code 2. 大佬请问一下,为啥我生成类型文件时报错
Found 2 errors in 2 files.
Errors Files 1 node_modules/@types/react-router-config/index.d.ts:12 1 node_modules/@types/react-router-dom/index.d.ts:14 error Command failed with exit code 2. 大佬请问一下,为啥我生成类型文件时报错
错误不具体,但看起来类型定义有问题,确认一下 @types/react-router-dom 版本是否存在冲突,并全仓库保持统一,如果是yarn就是yarn resolution,如果是 pnpm 就在.pnpmfile.cjs定义一下
node_modules/@types/react-router-config/index.d.ts:12:26 - error TS7016: Could not find a declaration file for module 'history'. '/Users/xxx/Desktop/hp-ui/xxxx/personal-code/hp-ui/node_modules/history/index.js' implicitly has an 'any' type. If the 'history' package actually exposes this module, consider sending a pull request to amend 'https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/history'
12 import { Location } from 'history';
node_modules/@types/react-router-dom/index.d.ts:14:20 - error TS7016: Could not find a declaration file for module 'history'. '/Users/xxx/Desktop/hp-ui/xxx/personal-code/hp-ui/node_modules/history/index.js' implicitly has an 'any' type.
If the 'history' package actually exposes this module, consider sending a pull request to amend 'https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/history'
14 import * as H from 'history';
Found 2 errors in 2 files.
Errors Files 1 node_modules/@types/react-router-config/index.d.ts:12
大佬请问yarn build:types时,报这种错就是版本冲突的问题吗?
node_modules/@types/react-router-config/index.d.ts:12:26 - error TS7016: Could not find a declaration file for module 'history'. '/Users/xxx/Desktop/hp-ui/xxxx/personal-code/hp-ui/node_modules/history/index.js' implicitly has an 'any' type. If the 'history' package actually exposes this module, consider sending a pull request to amend 'https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/history'
12 import { Location } from 'history';
~~~~~node_modules/@types/react-router-dom/index.d.ts:14:20 - error TS7016: Could not find a declaration file for module 'history'. '/Users/xxx/Desktop/hp-ui/xxx/personal-code/hp-ui/node_modules/history/index.js' implicitly has an 'any' type. If the 'history' package actually exposes this module, consider sending a pull request to amend 'https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/history'
14 import * as H from 'history';
~~~~~Found 2 errors in 2 files.
Errors Files 1 node_modules/@types/react-router-config/index.d.ts:12
大佬请问yarn build:types时,报这种错就是版本冲突的问题吗?
对的,统一一下 @types/react-router-dom 的版本哈,tsconfig 配置 skipLibCheck 应该也可以
我有一个问题、如果仅用gulp的话如何过滤掉一些仅仅申明却没有使用的代码
我有一个问题、如果仅用gulp的话如何过滤掉一些仅仅申明却没有使用的代码
这里的【过滤】我当成打包时的tree shaking 理解不知是否正确,取决于宿主项目的配置,比如 webpack。作为第三方库如果不做打包(rollup)只做编译(babel/tsc)一般不会做也不需要做额外处理,gulp 在这里只是一个 task runner
我有一个问题、如果仅用gulp的话如何过滤掉一些仅仅申明却没有使用的代码
这里的【过滤】我当成打包时的tree shaking 理解不知是否正确,取决于宿主项目的配置,比如 webpack。作为第三方库如果不做打包(rollup)只做编译(babel/tsc)一般不会做也不需要做额外处理,gulp 在这里只是一个 task runner
是的、就是 打包时的tree shaking ,gulp只做编译不做 tree shaking 库的体积就会比较大(多余的代码也会被打包)
我有一个问题、如果仅用gulp的话如何过滤掉一些仅仅申明却没有使用的代码
这里的【过滤】我当成打包时的tree shaking 理解不知是否正确,取决于宿主项目的配置,比如 webpack。作为第三方库如果不做打包(rollup)只做编译(babel/tsc)一般不会做也不需要做额外处理,gulp 在这里只是一个 task runner
是的、就是 打包时的tree shaking ,gulp只做编译不做 tree shaking 库的体积就会比较大(多余的代码也会被打包)
应当关注的是使用者打包他们应用时的我们组件库的体积,webpack 默认会做 tree shaking 的(package.json配置了sideEffects),再配个组件的按需引入,无需担心这一点哈,可以自己试验一下
我有一个问题、如果仅用gulp的话如何过滤掉一些仅仅申明却没有使用的代码
这里的【过滤】我当成打包时的tree shaking 理解不知是否正确,取决于宿主项目的配置,比如 webpack。作为第三方库如果不做打包(rollup)只做编译(babel/tsc)一般不会做也不需要做额外处理,gulp 在这里只是一个 task runner
是的、就是 打包时的tree shaking ,gulp只做编译不做 tree shaking 库的体积就会比较大(多余的代码也会被打包)
应当关注的是使用者打包他们应用时的我们组件库的体积,webpack 默认会做 tree shaking 的(package.json配置了sideEffects),再配个组件的按需引入,无需担心这一点哈,可以自己试验一下
感谢大佬百忙之中的秒回、感动。我想我应该明白了
我有一个问题、如果仅用gulp的话如何过滤掉一些仅仅申明却没有使用的代码
这里的【过滤】我当成打包时的tree shaking 理解不知是否正确,取决于宿主项目的配置,比如 webpack。作为第三方库如果不做打包(rollup)只做编译(babel/tsc)一般不会做也不需要做额外处理,gulp 在这里只是一个 task runner
是的、就是 打包时的tree shaking ,gulp只做编译不做 tree shaking 库的体积就会比较大(多余的代码也会被打包)
应当关注的是使用者打包他们应用时的我们组件库的体积,webpack 默认会做 tree shaking 的(package.json配置了sideEffects),再配个组件的按需引入,无需担心这一点哈,可以自己试验一下
感谢大佬百忙之中的秒回、感动。我想我应该明白了
能有帮助就好,遇到问题多交流哈
这个选项已经弃用了, 在 7.13.0
之后的版本可以根据 package.json 中的exports字段自动选择导入方式
配置@babel/plugin-transform-runtime的useESModules选项为true
这个选项已经弃用了, 在
7.13.0
之后的版本可以根据 package.json 中的exports字段自动选择导入方式 配置@babel/plugin-transform-runtime的useESModules选项为true
具体是哪个配置选项呀
这个选项已经弃用了, 在
7.13.0
之后的版本可以根据 package.json 中的exports字段自动选择导入方式 配置@babel/plugin-transform-runtime的useESModules选项为true具体是哪个配置选项呀
@babel/plugin-transform-runtime 插件的 useESModules 属性
有个疑问,最后style里面虽然生成了css.js
但是后面按需加载使用里面
import { Alert } from 'happy-ui'; import 'happy-ui/esm/alert/style';
css默认还是加载的style/index.js 文件啊,是不是要精确到css.js才好
有个疑问,最后style里面虽然生成了css.js 但是后面按需加载使用里面
import { Alert } from 'happy-ui'; import 'happy-ui/esm/alert/style';
css默认还是加载的style/index.js 文件啊,是不是要精确到css.js才好
可以通过配置 babel-plugin-import 参数决定引入 style/index.js(less) 还是 style/css.js(css),具体看使用者需求的。
有个疑问,最后style里面虽然生成了css.js 但是后面按需加载使用里面
import { Alert } from 'happy-ui'; import 'happy-ui/esm/alert/style';
css默认还是加载的style/index.js 文件啊,是不是要精确到css.js才好可以通过配置 babel-plugin-import 参数决定引入 style/index.js(less) 还是 style/css.js(css),具体看使用者需求的。
感谢 还有一个问题 看你上面说的主题定制可以通过css vars而不需要less,所以输出less的动机是啥,你也说了‘其实 css vars 也能做到,不一定要 less’实在想不到输出less的动机了,如果组件直接引入样式文件,应该也能完成组件吧
有个疑问,最后style里面虽然生成了css.js 但是后面按需加载使用里面
import { Alert } from 'happy-ui'; import 'happy-ui/esm/alert/style';
css默认还是加载的style/index.js 文件啊,是不是要精确到css.js才好可以通过配置 babel-plugin-import 参数决定引入 style/index.js(less) 还是 style/css.js(css),具体看使用者需求的。
感谢 还有一个问题 看你上面说的主题定制可以通过css vars而不需要less,所以输出less的动机是啥,你也说了‘其实 css vars 也能做到,不一定要 less’实在想不到输出less的动机了,如果组件直接引入样式文件,应该也能完成组件吧
用 less 开发也能享受预处理器
大佬,组件库编译出来的产物,需要使用babel转译吗,我看有的组件库是没有使用babel,产物就是兼容现代浏览器,如果需要兼容老版本,再从使用方引入babel
大佬,组件库编译出来的产物,需要使用babel转译吗,我看有的组件库是没有使用babel,产物就是兼容现代浏览器,如果需要兼容老版本,再从使用方引入babel
我文章里的产物是不需要的,这个看库维护者的考量了,可以提供多种 target 的产物,供用户选择,但我认为兼容老版本浏览器应该是默认行为,因为很多脚手架会在编译时把 node_modules exclude 掉,到时候 modern 产物在需要兼容低版本的场景线上白屏就是徒增烦恼,默认提供现代浏览器产物当然可以,但是使用者也必须知道这一点,这个信息的传递无疑是比较困难的。
前言
宿主环境各不相同,需要将源码进行相关处理后发布至 npm。
明确以下目标:
UMD
/Commonjs module
/ES module
等 3 种形式产物供使用者引入;css
引入,而非只有less
,减少业务方接入成本;然后,向目标前进!
导出类型声明文件
既然是使用
typescript
编写的组件库,那么使用者应当享受到类型系统的好处。我们可以生成类型声明文件,并在
package.json
中定义入口,如下:package.json
tsconfig.build.json
执行
yarn build:types
,可以发现根目录下已经生成了lib
文件夹(tsconfig.json
中定义的declarationDir
字段)以及esm
文件夹(拷贝而来),目录结构与src
文件夹保持一致,如下:lib
这样使用者引入
npm
包时,便能得到自动提示,也能够复用相关组件的类型定义。接下来将
ts(x)
等文件处理成js
文件。导出 Commonjs 模块
其实完全可以使用
babel
或tsc
命令行工具进行代码编译处理(实际上很多工具库就是这样做的),此处借助gulp
来串起这个流程。babel 配置
首先安装
babel
及其相关依赖新建
.babelrc.js
文件,写入以下内容:.babelrc.js
关于
@babel/plugin-transform-runtime
与@babel/runtime-corejs3
:helpers
选项设置为true
,可抽离代码编译过程重复生成的helper
函数(classCallCheck
,extends
等),减小生成的代码体积;corejs
设置为3
,可引入不污染全局的按需polyfill
,常用于类库编写(我更推荐:不引入polyfill
,转而告知使用者需要引入何种polyfill
,避免重复引入或产生冲突,后面会详细提到)。更多参见官方文档-@babel/plugin-transform-runtime
配置目标环境
为了避免转译浏览器原生支持的语法,新建
.browserslistrc
文件,根据适配需求,写入支持浏览器范围,作用于@babel/preset-env
。.browserslistrc
很遗憾的是,
@babel/runtime-corejs3
无法在按需引入的基础上根据目标浏览器支持程度再次减少polyfill
的引入,参见@babel/runtime for target environment 。这意味着
@babel/runtime-corejs3
甚至会在针对现代引擎的情况下注入所有可能的polyfill
:不必要地增加了最终捆绑包的大小。对于组件库(代码量可能很大),个人建议将
polyfill
的选择权交还给使用者,在宿主环境进行polyfill
。若使用者具有兼容性要求,自然会使用@babel/preset-env + core-js + .browserslistrc
进行全局polyfill
,这套组合拳引入了最低目标浏览器不支持API
的全部polyfill
。所以组件库不用画蛇添足,引入多余的
polyfill
,写好文档说明,比什么都重要(就像zent和antd这样)。现在
@babel/runtime-corejs3
更换为@babel/runtime
,只进行helper
函数抽离。.babelrc.js
gulp 配置
再来安装
gulp
相关依赖新建
gulpfile.js
,写入以下内容:gulpfile.js
修改
package.json
package.json
执行
yarn build
,得到如下内容:lib
观察编译后的源码,可以发现:诸多
helper
方法已被抽离至@babel/runtime
中,模块导入导出形式也是commonjs
规范。lib/alert/alert.js
导出 ES module
生成
ES module
可以更好地进行tree shaking,基于上一步的babel
配置,更新以下内容:@babel/preset-env
的modules
选项为false
,关闭模块转换;@babel/plugin-transform-runtime
的useESModules
选项为true
,使用ES module
形式引入helper
函数。.babelrc.js
目标达成,我们再使用环境变量区分
esm
和cjs
(执行任务时设置对应的环境变量即可),最终babel
配置如下:.babelrc.js
接下来修改
gulp
相关配置,抽离compileScripts
任务,增加compileESM
任务。gulpfile.js
执行
yarn build
,可以发现生成了lib
/esm
两个文件夹,观察esm
目录,结构同lib
一致,js 文件都是以ES module
模块形式导入导出。esm/alert/alert.js
别忘了给
package.json
增加相关入口。package.json
处理样式文件
拷贝 less 文件
我们会将
less
文件包含在npm
包中,用户可以通过happy-ui/lib/alert/style/index.js
的形式按需引入less
文件,此处可以直接将 less 文件拷贝至目标文件夹。在
gulpfile.js
中新建copyLess
任务。gulpfile.js
观察
lib
目录,可以发现less
文件已被拷贝至alert/style
目录下。lib
可能有些同学已经发现问题:若使用者没有使用
less
预处理器,使用的是sass
方案甚至原生css
方案,那现有方案就搞不定了。经分析,有以下 4 种预选方案:less-loader
。会导致业务方使用成本增加;css
文件,进行全量引入。无法进行按需引入;css in js
方案;style/css.js
文件,引入组件css
样式依赖,而非less
依赖,组件库底层抹平差异。重点看一看方案 3 以及方案 4。
css in js
除了赋予样式编写更多的可能性之外,在编写第三方组件库时更是利器。如果我们写一个
react-use
这种hooks
工具库,不涉及到样式,只需要在package.json
中设置sideEffects
为false
,业务方使用 webpack 进行打包时,只会打包被使用到的 hooks(优先使用 ES module)。入口文件
index.js
中导出的但未被使用的其他 hooks 会被tree shaking
,第一次使用这个库的时候我很好奇,为什么没有按需引入的使用方式,后来进行打包分析,发现人家天生支持按需引入。回到正题。如果将样式使用
javascript
来编写,在某种维度上讲,组件库和工具库一致了,配好sideEffects
,自动按需引入。而且每个组件都与自己的样式绑定,不需要业务方或组件开发者去维护样式依赖,什么是样式依赖,后面会讲到。
缺点:
styled-components
自带方法。需要看取舍了,偷偷说一句
styled-components
做主题定制也极其方便。方案 4 是
antd
使用的这种方案。在搭建组件库的过程中,有一个问题困扰了我很久:为什么需要
alert/style/index.js
引入less
文件或alert/style/css.js
引入css
文件?答案是管理样式依赖。
因为我们的组件是没有引入样式文件的,需要使用者去手动引入。
假设存在以下场景:使用者引入
<Button />
,<Button />
依赖了<Icon />
,则需要手动去引入调用组件的样式(<Button />
)及其依赖的组件样式(<Icon />
),遇到复杂组件极其麻烦,所以组件库开发者可以提供一份这样的js
文件,使用者手动引入这个js
文件,就能引入对应组件及其依赖组件的样式。那么问题又来了,为什么组件不能自己去
import './index.less'
呢?当然可以,但业务方需要配置
less-loader
。业务方不想配置
less-loader
?那我们import './index.css'
开发体验岂不是直线下降?所以需要一个两全其美的方案:
答案就是
css in js单独提供一份style/css.js
文件,引入的是组件css
样式文件依赖,而非less
依赖,组件库底层抹平差异。之前了解到 father 可以在打包的时候将
index.less
转成index.css
,这倒是个好法子,但是一些重复引入的样式模块(比如动画样式),会被重复打包,不知道有没有好的解决方案。生成 css 文件
安装相关依赖。
将
less
文件生成对应的css
文件,在gulpfile.js
中增加less2css
任务。执行
yarn build
,组件style
目录下已经存在css
文件了。接下来我们需要一个
alert/style/css.js
来帮用户引入css
文件。生成 css.js
此处参考antd-tools的实现方式:在处理
scripts
任务中,截住style/index.js
,生成style/css.js
,并通过正则将引入的less
文件后缀改成css
。安装相关依赖。
gulpfile.js
cssInjection
的实现:gulpfile.js
再进行打包,可以看见组件
style
目录下生成了css.js
文件,引入的也是上一步less
转换而来的css
文件。lib/alert
按需加载
在 package.json 中增加
sideEffects
属性,配合ES module
达到tree shaking
效果(将样式依赖文件标注为side effects
,避免被误删除)。使用以下方式引入,可以做到
js
部分的按需加载,但需要手动引入样式:也可以使用以下方式引入:
以上引入样式文件的方式不太优雅,直接入口处引入全量样式文件又和按需加载的本意相去甚远。
使用者可以借助 babel-plugin-import 来进行辅助,减少代码编写量(还是增加了使用成本)。
⬇️
最重要的构建流程到此结束,可以发现 sideEffects 字段对于非
CSS in JS
组件库用处并不大,还是依赖 babel 插件达到完整的按需引入效果。