-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
组件开发插件 #1550
Comments
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 具体做什么功能呢? |
如果不包含 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 中。 |
关于结构,我想分两个部分: umi-plugin-docz包含: docz 相关, doc 界面,doc的插件,对doc的增强,定制的东西比较多,比如支持 theme,相对 library 较独立。 使用方式: umi-plugin-library包含:打包, 可以打包任何东西,umi-tools build 能做吗? 使用方式: 其他使用方式 优点:看起来umi命令没那么多。 你们的意见呢? |
我的建议是这样,不侵入 umi 代码, $ umi docz build
$ umi docz dev
$ umi docz deploy 和 $ umi library dev
$ umi library build |
就 umi library 好了,docz 只是 umi library 依赖的文档工具,不需要在命令行展现。 |
好,我就这样先搞一波。 |
@clock157 是2012-12-13? 2018-12-13! |
$ umi lib dev
$ umi lib build 看看能不能加个 |
加了 #1585 一个 |
别名内置就好了,参考 |
|
按我理解,library 要么用 test 调,要么用 docz 调吧。 |
umi 的 library 可以在一些纯打包 component 的项目中使用吗?比如 ant-design。 目前有一些类似的方案:
|
@xiaoxiangmoe 这个需求就是为了解决这种场景,使得 umi 能够支持组件或者库的开发。 |
目前 library 实现了 dev 和 build,在这两个方向进行了一系列探索,反馈一下我的思路,大家有没有补充或问题: dev进度:可以正常调试,主题的还比较简陋。
build进度:可以打包组件,生成es5, es6 库文件,打的包已可以应用于项目。umd 还在调研
test进度: 测试还未推进,build 搞好学习下 antd 目前应用的 jest + enzyme。如有兴趣的同学可以帮下我,最近业务太忙了= =; |
我建议是直接用 af-webpack,既然在 umi 体系内,能复用的东西用一套就好,rollup 比起 webpack 其实没有本质的优势,遇到自定义配置时还得学和写另一套配置方式。 |
看下构建产物的区别呢?比如尺寸。 |
语雀那边组件开发需求蛮强烈的,bigfish 上了之后可以从他们那里开始试水。 |
我的想法。 基本思路
命令行$ umi lib doc dev
$ umi lib doc build
$ umi lib doc publish
$ umi lib build
$ umi lib test
$ umi lib publish 注:
配置方式
配置项
脚手架 MVP
package.json
src
dist (build 后输出)
|
参考
|
超赞!虽然我也调研过好些库,但是没有通过这样的形式进行整理和输出,知识成了个人的一次性消费,今后也要这样带着问题去调研和整理。😁 |
学习了,就是专业啊。不愧是我偶像 |
我还有很多疑问🤔️:
|
@xiaoxiangmoe 好问题,我找时间整理下。 |
好,等我先熟悉下 Typescript。
我倾向于 typescript 的方案全部统一到 babel 里做,这样可以顺便让 webpack 和 rollup 里保持一致,没必要有多种方案。cra 也是用的 babel 处理 typescript。
publish 不是核心功能,只做简单的,比如 changelog 生成、交互式升版本、打 tag、push 等。不做和 lerna 的整合,用 lerna 的场景直接用 lerna-changelog + lerna publish 就行了。
个人认为 cjs 是给 node 环境用的,因为 webpack/rollup 都走 esm 了,但不排除一些老的打包工具(比如 systemjs.js,webpack 1 等等)不支持 esm,还在使用 cjs。 理论上,给浏览器用的库且无 ssr 需求是可以不生成 cjs 格式,不过我觉得还是都提供吧,万一以后有 ssr 需求了呢?
jsnext:main 是技术发展的中间产物吧,现在应该不太用了。比如 webpack 默认的 resovle 字段是: 我的理解是:
我觉得可以提供,但默认先不开,然后输出名是
可以自行配置,但不内置的工具里。
处理 css 命名冲突的方案有很多,应用自己选就好了,工具层不做限制。
这也应该是工具使用者决定的,moment、react、react-dom 我觉得通常都不应该打到 umd 包里。
配置不在 package.json 里,而是作为插件的配置项。source 不支持,我觉得用不到。 |
cra 使用 babel 处理 TypeScript,但是禁止了 CustomTransformers 的使用,而我们未来可能会基于 TypeScript 的 CustomTransformers 做很多工作,比如非 js 文件的类型签名在编译期的生成和检查等(比如 css-module 的类型签名,现在我们只能基于 language service plugin 来做基于编辑器的编辑阶段的检查,而不会影响到编译期)。 Babel 的 AST 和 TypeScript 的 AST 差别挺大的,不方便做这些事情。我觉得我们应该推进 cra 使用 ts-loader 来支持 CustomTransformers。
也就是「我们每次的 publish 是人手动介入的,在 cli 里交互式地 publish」的意思吗? |
《如何打包组件?》Why,组件为什么要打包?
What
输出什么?
模块历史
通过 package.json 看各种格式
名词解释,ES6, ES2015, EMCAScript, JavaScript, ES Next ...
How
cjs
esm
umd
社区的库是怎么用的?
方案 |
2018 年最后一刻,提交了一版。剩下的 2019优化下 😂 https://github.com/umijs/umi-plugin-library/pull/new/refactor/use_monorepo_manage_project |
mark |
开发的组件变多之后,性能上很卡,很吃内存 |
继续学习。 |
背景
为了更方便的进行组件开发调试,并能很爽的写文档。在调研了流行的 storybook 和 docz 后,选型使用 docz,目前将计划开发
umi-plugin-docz
和umi-plugin-component
,在此跟进与讨论。项目地址
https://github.com/umijs/umi-plugin-library
进展
The text was updated successfully, but these errors were encountered: