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