Standardx setup for linting & code formatting #2992
Conversation
| @@ -1061,23 +1062,21 @@ export default class CodeEditor extends React.Component { | |||
| } = this.props | |||
| const fontFamily = normalizeEditorFontFamily(this.props.fontFamily) | |||
| const width = this.props.width | |||
| return (< | |||
| div className={ | |||
| return (<div | |||
There was a problem hiding this comment.
This is what I've meant in the PR comment.
<div className={...}
ref='root' ...>
Was a problem for standardx formatting. But after adding the new line before className the formating is OK.
I think that's OK but it was a bit weird during setup because the formatter introduced a linting error.
package.json
Outdated
| "lint-staged": { | ||
| "linters": { | ||
| "*.{js,jsx,mjs}": [ | ||
| "npm run lint:fix", |
There was a problem hiding this comment.
I'm not sure with this. I think I'd change to lint with-out fix to avoid introducing a problem during committing.
What do you think? Or should we use lint:fix and lint afterwards to check that the fix doesn't introduce an issue.
There was a problem hiding this comment.
Yeah it is wrong. We should do lint without fixing.
|
It sounds quite reasonable to use standardx although it cause tons of conflicts in other prs. @ZeroX-DG How do you think? |
|
@Rokt33r Indeed. Having this can significantly improve the development process. Although it causes conflict in other PR, I think most of the PRs are not very big so contributor can handle with resolving conflicts just fine. If we don't apply this improvement now and wait until all other PRs are merged, during that time, new PRs will jump in and it can cause a huge delay for this PR. I suggest we should apply this improvement now before other big PRs start to jump in. |
package.json
Outdated
| "lint-staged": { | ||
| "linters": { | ||
| "*.{js,jsx,mjs}": [ | ||
| "npm run lint:fix", |
There was a problem hiding this comment.
Yeah it is wrong. We should do lint without fixing.
…g issues (e.g. wrongly formatted code from standardx)
|
We can close this as we're using prettier now (already on master). |
Description
Similar to closed PR #924 I'd like to add code formatting with pre-commit hook. It will improve development experience as you don't have to care about semicolons, spacings etc. because it will be automatically formatted on save to a consistent code style.
I first wanted to go with prettier but it was problematic to have function paren formatting working.
Then I decided to use standard because it's exactly doing what we need with an exception - it can't be customized.
So in the end I'm using standardx - it is using standard lib under the hood but can be customized.
The only drawback of standardx is that vscode can only use standard and that's why I have added the configuration into
package.jsonas well. So vscode is usingpackage.jsonandyarn lintis using.eslintrcfile.Not perfect but I think OK to start with. Once the PR is merged / released we can use Standardx in VS code and remove the config from
package.json.Styles we're having (basically according to standard style - just to mention some of the styles):
Summary
settings&recommendations--no-verifycommand line arg)eslint-disable-lineto remove some warnings. We could fix these later:ComponentWillReceiveProps- not sure why the unsafe use warning from linting is not presentReact-Appis adding accessibility rules like this.Points I've noticed during setup
<div someProps={ }and then the next prop in the next line couldn't be indented correctly. (I'll add an inline comment to this later.)Issue fixed
Type of changes
Checklist:
Demo editing with Standardx formatting & linting
Note: The prop typo is not detected in VS code because it's using
standardinstead ofstandardx. Formatting is happening on save (ctrl+s).Demo - Failing pre-commit hook
Note: Coloring of the error is not correctly displayed in the recording. But I've fixed that by forcing the coloring.
Here is a test file where I've checked the linting rules.