Thank you all. I think we mostly agree that we can benefit a lot from the auto-formatting tools, the only controversial question is if the benefit is worth the price. Please comment more about what you think and maybe a vote is required later to make the final decision.
Thanks *Ovilia* On Wed, Jun 8, 2022 at 3:47 PM Zhongxiang Wang <wan...@apache.org> wrote: > Hi, I'm afraid that I have the opposite view. > It's enough for me to follow the defined code style manually during > the development process and if we have installed ESLint and EditorConfig > extensions in our IDE, the tools will give us corresponding warnings or > errors on time and even one-click fix strategies. > I think it won't be something hard for us to fix these lint issues when we > are making changes for a bug fix or a new feature, as we usually only need > to modify a few specified files. > Also, we have enabled `husky` to do the lint check before each commit. > In a word, I personally don't second to make huge changes to fix current > remained lint issues. They can be fixed one by one in future bug fixes and > new features. > > Thanks. > > On Wed, Jun 8, 2022 at 2:30 PM Yi Shen <shenyi....@gmail.com> wrote: > > > I would love to use prettier in the Apache ECharts project. > > > > The only concern is that it will bring massive code changes and make it > > hard to trace the git history and blame the changed code. > > > > On Tue, Jun 7, 2022 at 10:37 AM Ovilia <oviliazh...@gmail.com> wrote: > > > > > Hi Doma, > > > > > > Thanks for your comments. > > > An example of the previous git blame problems is that the last change > of > > > much of current code refers to > > > the commit when we change to es6 module [1]. > > > > > > [1] > > > > > > > > > https://github.com/apache/echarts/blame/master/src/action/roamHelper.ts#L56-L60 > > > > > > Thanks > > > > > > *Ovilia* > > > > > > > > > On Mon, Jun 6, 2022 at 7:15 PM Lei Shenghao <leisheng...@126.com> > wrote: > > > > > > > Hi Ovilia, > > > > > > > > I think it’s a good idea to use auto formatting tools which can > prevent > > > > whitespace changes/quote changes in PRs. > > > > > > > > I would suggest approach a which makes source code immediately > benefit > > > > from auto formatting. And it should not really spoil git-blame if it > > > > happens in only one commit and with clear commit message, especially > > when > > > > the community is broadly familiar with conventional commit message. > > > > Readers would go git-blame and find "this line was updated by the > > commit > > > > style: format code with prettier" and realize they should go for > > previous > > > > commits. > > > > > > > > Doma > > > > > > > > > 在 2022年6月6日,15:21,Ovilia <oviliazh...@gmail.com> 写道: > > > > > > > > > > Hi, > > > > > > > > > > I would like to know if you think using auto-formatting tools like > > > > prettier > > > > > is a good idea. > > > > > The pros are pretty clear: It helps formatting the code in a > > uniformed > > > > > style without our consideration. > > > > > > > > > > But for the current code that doesn't follow the style rules, we > can > > > > choose > > > > > a. Fix all the code styles once in a single PR > > > > > b. Fix the code styles in a file when it is changed in a future PR > > > > > > > > > > If we choose plan a, the last change of most lines would be this PR > > and > > > > > lose the help of "git blame". > > > > > If we choose plan b, for many times the project would have > different > > > > styles > > > > > over different files and many of future PRs will have styling > > changings > > > > > which make the PR a little harder to review. > > > > > > > > > > So I would like to know if you think the help from auto-formatting > > > tools > > > > is > > > > > worth the price and which plan we should take for historical > styling > > > > > problems. > > > > > > > > > > Thanks > > > > > > > > > > *Ovilia* > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@echarts.apache.org > > > > For additional commands, e-mail: dev-h...@echarts.apache.org > > > > > > > > > > > > > > > > > -- > > Yi Shen > > Apache ECharts PMC > > >