了解css-tree
CSSTree is a tool set for CSS: fast detailed parser (CSS → AST), walker (AST traversal), generator (AST → CSS) and lexer (validation and matching) based on specs and browser implementations. The main goal is to be efficient and W3C spec compliant, with focus on CSS analyzing and source-to-source transforming tasks.
为什么使用它?
最近项目上有个需求:提供一个界面化的css代码编辑器,管理员可以输入css代码配置修改表单/组件的一些默认样式,从而针对不同业务需求实现不同的界面呈现效果。
为了避免样式的全局污染,需要对配置的样式添加默认前置导航,通过属性选择器约束样式的生效范围。如果通过string的一些方法粗暴的对样式进行替换or正则匹配,有很大的局限性,同时也不符合规范。
思考再三,找到了css -> ast -> css.方案,并通过css-tree的API实现。
根据产品业务的区别,如果只是想实现样式自定义,不需要通过代码配置达到更强的交互,那么可以内置class,编写默认的一些style,用户通过在界面选择主题来实现该效果。参考百度amis
lerna是什么?
Lerna is a fast modern build system for managing and publishing multiple JavaScript/TypeScript packages from the same repository.
为什么要用lerna?
官方解释:
Lerna 在 repo 中链接不同的项目,因此它们可以相互导入,而无需向 NPM 发布任何内容
Lerna 对任意数量的项目运行命令,它以最有效的方式、以正确的顺序执行它,并且可以将其分布在多台机器上
Lerna 管理您的发布流程,从版本管理到发布再到 NPM,它提供了多种选项来确保可以适应任何工作流程
结合工作中的实际体验,谈谈我的看法:
公司一般都有自己的 npm 私库,有很多的 package 相互之间存在或多或少的关联。随着业务需求的不断升级,我在维护这些 package 的时候就碰到了一个很操蛋的问题:比如我改了 packageA 然后发布,那么所有用到了 packageA 的其他 package,也要跟着升级 packageA 的依赖,然后再发布,过程显得很是繁琐,此时如果你的 package 是通过 lerna 管理,就可以很好的避免这个问题。
为什么是eslint和prettier?
在
ESlint推出--fix参数前ESLint并没有自动化格式代码的功能,要对一些格式问题做批量格式化只能用Prettier这样的工具。并且Prettier在代码风格的检测上比ESlint更全面,所以两者通常是结合在一起使用的。
对
typescript代码进行linting时,有两个主要的linting工具可供选择:tslint、eslint,tslint是一个只能用于typescript项目的linter,而eslint同时支持typescript、javascript.
据
typescript核心团队解释:ESLint 具有比 TSLint 更高性能的架构,并且后续在为typescript中linting集成时,只会关注eslint,另外官方自2019起已经弃用tslint,**TSLint has been deprecated as of 2019**