为了更方便的进行组件开发调试,并能很爽的写文档。在调研了流行的 storybook 和 docz 后,选型使用 docz,目前将计划开发 umi-plugin-docz 和 umi-plugin-component,在此跟进与讨论。
https://github.com/umijs/umi-plugin-library
umi-plugin-component 改成 umi-plugin-library 吧,通用的,不只是 component。
cc @zinkey
就搞一个 umi-plugin-docz 就行,过度分层也没必要。
那应该是 umi-plugin-library 这个插件,然后里面有 docz 这个的一个配置?
plugins: [[
'umi-plugin-library',
{
docz: true,
}
]]
umi-plugin-library 具体做什么功能呢?
umi-plugin-library 具体做什么功能呢?
如果不包含 doc 的话主要就是构建打包这块,库,组件和应用的打包方式不一样。比如说:
docz 也包含了 build,那就是不用 docz 的 build?那 dev 是否包含呢?要是 umi-plugin-library 只包含 build 好像不是很好用,不如给个 umi-plugin-docz dev,build 都有
docz 只是文档,不会包含 library 的 build 的,library 的 build 得通过 rollup 来做。
docz 不仅仅是文档,包含了 build 的
这个 build 分为两种,一种是 doc site build ,另一种是 component 的 build,component 的 build 应该放在 library 中。
如果不分层,将docz 放在 umi-plugin-library中,那 library 同时可以 build doc 也可以 buid component。
关于结构,我想分两个部分:
包含: docz 相关, doc 界面,doc的插件,对doc的增强,定制的东西比较多,比如支持 theme,相对 library 较独立。
使用方式:
umi doc [--dev] // 跑 doc server
umi doc --build // build
umi doc --deploy // 部署
包含:打包, 可以打包任何东西,umi-tools build 能做吗?
使用方式:
umi library --build [ --input /src/component --output /lib ]
其他使用方式
umi dev --doc?
umi build --doc ?
umi build --library ?
优点:看起来umi命令没那么多。
缺点:侵入 umi代码。
你们的意见呢?
我的建议是这样,不侵入 umi 代码,
$ umi docz build
$ umi docz dev
$ umi docz deploy
和
$ umi library dev
$ umi library build
就 umi library 好了,docz 只是 umi library 依赖的文档工具,不需要在命令行展现。
就 umi library 好了,docz 只是 umi library 依赖的文档工具,不需要在命令行展现。
好,我就这样先搞一波。
@clock157 是2012-12-13? 2018-12-13!
$ umi lib dev
$ umi lib build
看看能不能加个 lib 的 alias,毕竟最后也是放到 lib 目录
加了 https://github.com/umijs/umi/pull/1585 一个 _modifyCommand 这个插件方法,可以实现命令行别名。
别名内置就好了,参考 umi g 和 umi generate。
umi library dev 需要调用 umi dev 吗?还是说完全独立的一套构建?
按我理解,library 要么用 test 调,要么用 docz 调吧。
umi 的 library 可以在一些纯打包 component 的项目中使用吗?比如 ant-design。
目前有一些类似的方案:
@xiaoxiangmoe 这个需求就是为了解决这种场景,使得 umi 能够支持组件或者库的开发。
目前 library 实现了 dev 和 build,在这两个方向进行了一系列探索,反馈一下我的思路,大家有没有补充或问题:
进度:可以正常调试,主题的还比较简陋。
进度:可以打包组件,生成es5, es6 库文件,打的包已可以应用于项目。umd 还在调研
testumilibrary-ant-design-pro 有兴趣可以看下,可以跑起来,样式正常。进度: 测试还未推进,build 搞好学习下 antd 目前应用的 jest + enzyme。如有兴趣的同学可以帮下我,最近业务太忙了= =;
我建议是直接用 af-webpack,既然在 umi 体系内,能复用的东西用一套就好,rollup 比起 webpack 其实没有本质的优势,遇到自定义配置时还得学和写另一套配置方式。
rollup 的优势是 treeshaking, 现在 webpack 也支持,还有其他优点吗?
看下构建产物的区别呢?比如尺寸。
语雀那边组件开发需求蛮强烈的,bigfish 上了之后可以从他们那里开始试水。
我的想法。
umi-plugin-library 露出umi-plugin-docz 里,然后在 umi-plugin-library 里调他,并透传参数$ umi lib doc dev
$ umi lib doc build
$ umi lib doc publish
$ umi lib build
$ umi lib test
$ umi lib publish
注:
umi lib 为 umi library 的别名['umi-plugin-library', {}]src/index.(t|j)sx?仅考虑 build 部分,实际脚手架需添加 doc 和 test 部分。
调研笔记。
@babel/plugin-transform-runtime 要不要加 polyfill?doc dev 和 doc buildmicrobundle src/index.mjs -f es,umd --no-sourcemap --target weblerna run --parallel buildscript type="module"sideEffect: false 或者 sideEffect: [文件1, 文件2]['umi-plugin-library', {}]src/index.jsreact:React,'react-dom':ReactDOMrollup | babellibtrue | falserollup | babelesfoodist/foo.jsdist/foo.esm.jsdist/foo.umd.js-w, --watch超赞!虽然我也调研过好些库,但是没有通过这样的形式进行整理和输出,知识成了个人的一次性消费,今后也要这样带着问题去调研和整理。😁
学习了,就是专业啊。不愧是我偶像
我还有很多疑问🤔️:
entry: String | Object,umd: Object | false,很多地方用了 Array 和 Object,而这里面具体是 Array<String>,还是 Array<{foo:string,bar?:number,baz:number|string}> ,作为文档的阅读者,我并不清楚这些,建议用更严格的 TypeScript 类型签名指定<package>.module 字段和 moment 里的<package>."jsnext:main"字段有什么关系?<package>.typings和<package>.types有什么区别?type='module'使用?比如 foo.esm.min.jssource 字段?这会影响到下游的 source package 的使用吗?比如 https://github.com/parcel-bundler/parcel/pull/1101 @xiaoxiangmoe 好问题,我找时间整理下。
- 比如
entry: String | Object,umd: Object | false,很多地方用了 Array 和 Object,而这里面具体是Array<String>,还是Array<{foo:string,bar?:number,baz:number|string}>,作为文档的阅读者,我并不清楚这些,建议用更严格的 TypeScript 类型签名指定
好,等我先熟悉下 Typescript。
- build,基于 rollup + babel,那么是通过 babel 提供 TypeScript 的支持,还是 rollup-plugin-typescript2 提供 TypeScript 支持,比如 rollup-plugin-typescript2 的一些配置,比如 transformers,babel 是否有对应的解决方案?
我倾向于 typescript 的方案全部统一到 babel 里做,这样可以顺便让 webpack 和 rollup 里保持一致,没必要有多种方案。cra 也是用的 babel 处理 typescript。
- publish 是在 ci 上 push 到某个分支执行,还是得用户手动执行,是否要测试和 lerna 的 publish 的兼容性,因为 lerna 以及它的插件也提供了 changelog/commit/tag/push 等功能
publish 不是核心功能,只做简单的,比如 changelog 生成、交互式升版本、打 tag、push 等。不做和 lerna 的整合,用 lerna 的场景直接用 lerna-changelog + lerna publish 就行了。
- 纯网页端的库是否要提供 cjs?(是否有无浏览器运行的测试库依赖 cjs? ssr 可以不依赖 cjs 吗?)
个人认为 cjs 是给 node 环境用的,因为 webpack/rollup 都走 esm 了,但不排除一些老的打包工具(比如 systemjs.js,webpack 1 等等)不支持 esm,还在使用 cjs。
理论上,给浏览器用的库且无 ssr 需求是可以不生成 cjs 格式,不过我觉得还是都提供吧,万一以后有 ssr 需求了呢?
<package>.module字段和 moment 里的<package>."jsnext:main"字段有什么关系?<package>.typings和<package>.types有什么区别?
jsnext:main 是技术发展的中间产物吧,现在应该不太用了。比如 webpack 默认的 resovle 字段是:browser -> module -> main,所以写了通常也没有用。
我的理解是:
src/index.js参考:https://github.com/jsforum/jsforum/issues/5
- es module 是否要提供压缩版本的,给浏览器端的
type='module'使用?比如foo.esm.min.js
我觉得可以提供,但默认先不开,然后输出名是 foo.mjs 和 foo.min.mjs。另外,这种使用方式短时间内我觉得流行不起来,在我调研的库里只有 redux 里有输出这种格式。
- 是否要提供 css 的 tree shaking?我们因为库很庞大时候,css 代码可能会很多,有 TypeScript 的 transformer 做了类似的事情:https://github.com/Brooooooklyn/ts-import-plugin
可以自行配置,但不内置的工具里。
- 由于是提供库,我们是否要提供 css 的 class 名的规则自定义?毕竟不是直接最下游的用户,可以无脑 uglify 加 hash
处理 css 命名冲突的方案有很多,应用自己选就好了,工具层不做限制。
- 哪些包应该打包进 umd,哪些应该作为依赖?我用 umd 会不会出现上游的 A 和 B 都依赖 moment,于是我加载了两个 moment?
这也应该是工具使用者决定的,moment、react、react-dom 我觉得通常都不应该打到 umd 包里。
- 可指定 entry,entry 是否要像 micro bundle 里一样使用
source字段?这会影响到下游的 source package 的使用吗?比如 https://github.com/parcel-bundler/parcel/pull/1101
配置不在 package.json 里,而是作为插件的配置项。source 不支持,我觉得用不到。
我倾向于 typescript 的方案全部统一到 babel 里做,这样可以顺便让 webpack 和 rollup 里保持一致,没必要有多种方案。cra 也是用的 babel 处理 typescript。
cra 使用 babel 处理 TypeScript,但是禁止了 CustomTransformers 的使用,而我们未来可能会基于 TypeScript 的 CustomTransformers 做很多工作,比如非 js 文件的类型签名在编译期的生成和检查等(比如 css-module 的类型签名,现在我们只能基于 language service plugin 来做基于编辑器的编辑阶段的检查,而不会影响到编译期)。
Babel 的 AST 和 TypeScript 的 AST 差别挺大的,不方便做这些事情。我觉得我们应该推进 cra 使用 ts-loader 来支持 CustomTransformers。
publish 不是核心功能,只做简单的,比如 changelog 生成、交互式升版本、打 tag、push 等。
也就是「我们每次的 publish 是人手动介入的,在 cli 里交互式地 publish」的意思吗?
内部分享版。
src -> dist,做输出,给项目用
--experimental-modules flagscript type="module"sideEffect: false 或者 sideEffect: [文件1, 文件2]microbundle src/index.mjs -f es,umd --no-sourcemap --target weblerna run --parallel buildhttps://github.com/umijs/umi/issues/1550#issuecomment-449780074
2018 年最后一刻,提交了一版。剩下的 2019优化下 😂
https://github.com/umijs/umi-plugin-library/pull/new/refactor/use_monorepo_manage_project
已可用,后续改进在 https://github.com/umijs/umi-plugin-library/issues 跟进。
mark
开发的组件变多之后,性能上很卡,很吃内存
继续学习。
Most helpful comment
@babel/plugin-transform-runtime要不要加 polyfill?doc dev和doc buildmicrobundle src/index.mjs -f es,umd --no-sourcemap --target weblerna run --parallel buildscript type="module"sideEffect: false或者sideEffect: [文件1, 文件2]['umi-plugin-library', {}]src/index.jsreact:React,'react-dom':ReactDOMrollup | babellibtrue | falserollup | babelesfoodist/foo.jsdist/foo.esm.jsdist/foo.umd.js-w, --watch参考