@kensoz 看了一下主要是支持 import/export 语法的吧，这个如果用 TS 的话，可以用 TypeScript 的 Parser 解决，如果写 JS 一般也可以用 Babel Parser 解决。

@a1248499257 这倒是没有，可以给 eslint-plugin-prettier 提个 Issue

@kensoz 还有这玩意，我研究研究

@kensoz

@robinlovemaggie 所以我才把它们都总结起来，方便其它人可以在 ddl 前搞完项目

@connection 这里你说的 pre-commit eslint 检测是指不用 prettier 插件来 fix 么？但是如果这样的话，就用不了 prettier/prettier 规则了，在 IDE 不会报错诶

@shyling 是的，这些配置都可以用 --init 来初始化，这里主要是不想写太多干扰项~以及方便引出后续~

@Trim21 哦，把这玩意忘了，看 Issue 的时候是看过，当时看这 Github star 太少了，感觉不是很官方就给忘了，回头试试

@makelove 我刚开始也是这么想的，不过 eslint x prettier 可在 IDE 里直接有提示自动修复还是挺好的，而且也能自动有报错提示，不跑 eslint --fix 其实还好~

@datian9966 thx 🤟

@wu67 现在的 IDE 和 vscode 都集成得很好了，这里主要是梳理一下这些工具之间的关系~

@TomatoYuyuko 这些小工具是很蛋疼

@defunct9 👍

自己平常也写小玩意，个人觉得是否有趣来自于创新，而创新的前提是有足够多的抄袭。如果没有足够多的重复，要么你觉得这东西很简单，老子不屑于做，要么觉得这东西太难了，小白的我做不了，可能更多人觉得这东西都做出来的了，我还有做的必要么？实际上，无论你看哪个开源项目，就算是 Vue 或者 React 要也，它们都有自己的 Bug 和问题，并不是做了就不能再做了，也不是有了就等于完美的。可以先从自身的需求入手，造点轮子或者做个网页都行，实在没 Idea 了，就多抄抄别人的，只要深入了解某个轮子 /产品了，必然会发现里面的问题，这就是创新的时候了。

具个例子：假如你此时在开发 Button 组件，但是开发着开发着发现 Navigation 组件有个特别小特别小的 Bug ，比如说写了个双等号，要改成三等号。
如果有没有中间的 Stage ，你就必须写完 Button 再改 Navigation ，或者先改 Navigation 再开发 Button 。
如果有中间态，那你可以两个都同时改了，提交的时候选 Button 的文件提交，再选 Navigation 的改动提交，变变成两次很清晰的提交，而不是像 git commit -a 无脑提交，别人 Review 代码的时候就会纳闷：你开发个 Button ，搞 Navigation 干嘛。
总的来说，git stage 可以让 git 操作更加精细，也就你说的灵活。当然这也只是 stage 的一个好处，还有在做 git diff 时也是很有帮助的。

@AoEiuV020 我傻了

@sillydaddy
账号：user
密码：user

提个刁钻的角度：假如要边聊天边切换不同 App，小程序就做不到了吧 = =