refactor: apply prettier
#694
Conversation
|
Sounds good. I would like to release just these formatting updates in its own release so that any functionality changes between versions won't get muddled with all these formatting-only changes. So feel free to do all the formatting changes here but don't merge to main before all formatting and linting related changes are done and then we'll ship all in one version with no other changes. |
|
@valscion I want to split them into 2 PRs for better diff and review, here is just formatting, nothing more, so code is the same, eslint will have more changes - like more ES6 syntax, refactor forEach to for/of (perf), using built-in hawOwn and etc, that is why better to split them into 2 PRs And after merge this and updating eslint configuration, we can make a release |
|
OK, so when the next PR comes then point it towards this branch for easier reviewing — until we are good to go with all the PRs. |
|
@valscion I can, but I just don't understand why complicate a simple process if it's literally just stylistic changes, multiple branch, merging with rebasing, and other changes, that will be soon to be align with our other repos - all of these only adds complexity to a fairly simple process, I will raise an issue in TSC to avoid such things in future |
|
Hmm yeah you're probably right. I'll just release the unreleased code once I have a good slot and then main is clear. |
|
@valscion We don't need to make a release right now, let's just merge and continue working on the next PRs (review/merge), we are working on modernization |
Summary
Apply prettier, after this I will focus on eslint
Ref: webpack/tsc#40
Ref:
What kind of change does this PR introduce?
refactor
Did you add tests for your changes?
Existing
Does this PR introduce a breaking change?
No
If relevant, what needs to be documented once your changes are merged or what have you already documented?
Nothing