Chen Yangjian
Chen Yangjian
这个我赞成，“文档” 部分的作用也找到了，顶
不用这么客气啦，不然交流起来好奇怪。我们下周小组内 review 一下 cube 吧
工作流程的选择： - 使用 gh-pages 分支，grunt daily 到日常环境，grunt deploy 到线上 CDN - 使用 daily/1.0.8 分支做日常开发，git push gitlab daily/1.0.8，git tag publish/1.0.8 发布 如果熟悉 gitlab 本身那一套工作方式，直接采用后者，绕过 grunt daily 与 Grunt deploy 任务也无不可。 但是要记得同步...
已完成 - grunt daily 发布到日常 - grunt deploy 发布到线上
@juukee 在维护的呀，为啥会有这样的疑问嘞
the bad part of this design is if user wants to construct query conditionally, they'd have to define the query as mutable, such as: ```js let query = Post.where({ published:...
比较赞同 @sapjax 的说法。 单纯的 CSS “模块化”没什么好说的，用 webpack 还是直接写 JS 对象字面量还是用其他预编译手段都能把 CSS 当成 JS 处理，各个模块的依赖关系也都好办。但是 CSS **级联** 的特征决定就目前而言没办法很好地将其组件化，自己去 shim `` 代价可小不了。 我们通常考虑 `class` 或者 `id` 的唯一性，但别忘了组件嵌套的时候，父组件样式穿透到子组件，导致子组件自身样式不足以正常显示，还得写补丁代码的情况。所以 web component 这一套在我看来是必须的，而 CSS 代码写在哪里，只是见仁见智的东西。
compiling to `:is()` is correct ideally but not very practically, specially if the user needs to be dealing with Chrome < 88, which still is quite often across those electron...
aha, totally missed that comment, I won't how postcss-nesting does it, which is the one we're using at the moment.
so that leaves us with not much options then. Projects that still need to support chrome < 88 should be using postcard-nesting even though it is no longer maintained.