了解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**