This will close #3413.

I guess this PR also closes #3315 ?

This will close #3413.

I guess this PR also closes #3315 ?

Yes, everything related to upgrading node can be closed

I understand this is now an annoying request, can you please remove all reformatting-only changes from the code?

I would very much prefer that we decide afterwards what formatting we use and then do one "global reformatting" PR

If I understood correctly, the format change was automatically done by the "precommit": "pretty-quick --staged" setting in package.json and due to some changes in the prettier? I agree it is annoying. But the work to upgrade versions is already a pain. I think it's better to get it done in one round, but not make it more complicated. If the solution is to temporarily remove / disable the setting now and re-add / enable it later, it is counterproductive.

Note: the last commit 9c667eb has no content. It changed nothing.

If I understood correctly, the format change was automatically done by the "precommit": "pretty-quick --staged" setting in package.json and due to some changes in the prettier? I agree it is annoying. But the work to upgrade versions is already a pain. I think it's better to get it done in one round, but not make it more complicated. If the solution is to temporarily remove / disable the setting now and re-add / enable it later, it is counterproductive.

Note: the last commit 9c667eb has no content. It changed nothing.

Yes, I thought I changed it, but after submitting it, I found it was done automatically, and I didn't make any changes to the configuration file. Now I have restored the file after closing it.

If I understood correctly, the format change was automatically done by the "precommit": "pretty-quick --staged" setting in package.json and due to some changes in the prettier? I agree it is annoying. But the work to upgrade versions is already a pain. I think it's better to get it done in one round, but not make it more complicated. If the solution is to temporarily remove / disable the setting now and re-add / enable it later, it is counterproductive.

Note: the last commit 9c667eb has no content. It changed nothing.

"Precommit" is only valid for the file that was added to "git commit" last time.

@xiangxn I want to say that we should not waste time arguing about code format or even reformatting code manually. If the prettier is working, just let it do it.

Reformatting due to changed formatter and business logic should be done separately, simply for the sake of conflicts. It's not a blocker for this PR, but it's annoying.

Let's discuss a global reformating #3418

Reformatting due to changed formatter and business logic should be done separately, simply for the sake of conflicts. It's not a blocker for this PR, but it's annoying.

Let's discuss a global reformating #3418

These formatting issues are not because I used the formatter alone. This is entirely due to the automatic completion of the new dependent tools. I have not updated the versions of these tools, so will these format changes be the previous abnormal format?
I don't know who added "pretty-quick", and whether everyone uses it normally.
Since the "pretty-quick" tool will only work on the files in the new "commit", no matter whether you use a separate PR to deal with the problem, once someone modifies the file, it will cause the "pretty-quick --staged" pair Format standardization. So I think it is unwise to use a PR to solve the formatting problem. Unless you decide to cancel the "pretty-quick" job.

2. You switched now to yarn in travis and appveyor. travis would be outdated anyways, so doesnt matter. In any case, we decided to use npm (package.lock) as source of truth, and keep a yarn in sync), didn't we? In any case, you have not changed package.lock, so that one would be out of sync now

Just found that the URLs in yarn.lock now are from npm sources but not mirrors. I thought we would use mirrors for developers in China, but it seems it's not the case. Perhaps we remove package-lock.json if yarn is easier to use? Anyway, both of them are generated from package.json. Why don't we make a workflow in Github Actions to generate them automatically? I'm not a UI developer, to be honest I don't know what is the best.

IMHO making progress is more important than making things perfect. Please avoid endless discussions.

3. You switched now to yarn in travis and appveyor. travis would be outdated anyways, so doesnt matter. In any case, we decided to use npm (package.lock) as source of truth, and keep a yarn in sync), didn't we? In any case, you have not changed package.lock, so that one would be out of sync now

Just found that the URLs in yarn.lock now are from npm sources but not mirrors. I thought we would use mirrors for developers in China, but it seems it's not the case. Perhaps we remove package-lock.json if yarn is easier to use? Anyway, both of them are generated from package.json. Why don't we make a workflow in Github Actions to generate them automatically? I'm not a UI developer, to be honest I don't know what is the best.

IMHO making progress is more important than making things perfect. Please avoid endless discussions.

After repeated testing and installation of dependency packages, I found that the current dependency can hardly be completed with npm. This is not only because of the source problem, but also because yran and npm deal with upstream dependency conflicts differently. Even if it is not in China, yarn's work is still better than npm, you can use npm and yran to test the installation dependencies separately to verify what I said.

What's the reason for changing node-sass to sass?

After upgrading node, there was a serious dependency package conflict, which was actually caused by this package.

https://github.com/sass/node-sass/blob/master/README.md#node-sass

Although there are package conflicts, yarn can handle them perfectly.
In addition, we may have to abandon npm. This is the result of my repeated testing:

What's the reason for changing node-sass to sass?

After upgrading node, there was a serious dependency package conflict, which was actually caused by this package.

https://github.com/sass/node-sass/blob/master/README.md#node-sass

Although there are package conflicts, yarn can handle them perfectly. In addition, we may have to abandon npm. This is the result of my repeated testing:

Thanks, clear!

FWIW in

https://github.com/sass/node-sass/blob/master/README.md#node-sass

It says

Warning: LibSass and Node Sass are deprecated.
While they will continue to receive maintenance releases indefinitely, there are no
plans to add additional features or compatibility with any new CSS or Sass features.
Projects that still use it should move onto
Dart Sass.

Fonts and icons are not being formatted properly, CSS was also an issue

Fixed with latest commits

Deployment to https://develop.bitshares.org/ successful as well
https://github.com/bitshares/bitshares-ui/runs/4612274797