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
> >
>

Reply via email to