-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lint: Add support for CSS stylesheets in linting workflow. #66
Changes from 39 commits
24a30ab
653e71b
c1e9aa6
64a751c
c95c20c
308c319
8cd6e29
b71d699
b09f16e
12a8bab
2c3c242
676e929
0a18614
e14fd6e
78a859a
764ab4f
d07d9b3
c1ab8fd
7706e45
c7b50fc
3de697f
bb9307d
ccc8a47
8f420b4
bafc21b
dae94ae
4268be5
94387dc
bf6b072
64b465a
64e7197
009f24d
5481538
0c6fa4f
52beffc
b6db9a1
dbd2e87
c597457
c0d4b71
fff19ae
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,6 @@ | ||
tabWidth: 4 | ||
useTabs: false | ||
singleQuote: false | ||
quoteProps: consistent | ||
printWidth: 100 | ||
endOfLine: lf |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,7 @@ | ||
{ | ||
"extends": [ | ||
"stylelint-config-standard", | ||
"stylelint-config-clean-order/error", | ||
"stylelint-prettier/recommended" | ||
] | ||
} |
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -5,10 +5,13 @@ | |
"main": "src/index.tsx", | ||
"scripts": { | ||
"build": "webpack --config webpack.prod.js", | ||
"start": "webpack serve --open --config webpack.dev.js", | ||
|
||
"lint": "npm run lint:check", | ||
"lint:check": "eslint src webpack.*.js --max-warnings 0", | ||
"lint:fix": "npm run lint:check -- --fix", | ||
"start": "webpack serve --open --config webpack.dev.js" | ||
"lint:check": "npm-run-all --sequential --continue-on-error lint:check:*", | ||
"lint:check:css": "stylelint src/**/*.css --formatter github", | ||
"lint:check:js": "eslint src webpack.*.js --max-warnings 0", | ||
"lint:fix": "npm-run-all --parallel --continue-on-error \"lint:check:* -- --fix\"" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I guess the parallel might be slightly more convenient, but maybe could cause issues if the linters touch the same files? If they don't, im okay with it. If they do, maybe just use sequential to be safer There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Supposedly no at the moment. ESLint would only look into js, jsx, ts, and tsx files and we're asking Stylelint to look only into css files. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. okay ltgm |
||
}, | ||
"repository": { | ||
"type": "git", | ||
|
@@ -49,8 +52,14 @@ | |
"html-webpack-plugin": "^5.6.0", | ||
"mini-css-extract-plugin": "^2.9.0", | ||
"monaco-editor-webpack-plugin": "^7.1.0", | ||
"npm-run-all": "^4.1.5", | ||
"prettier": "^3.3.3", | ||
"react-refresh": "^0.14.2", | ||
"style-loader": "^4.0.0", | ||
"stylelint": "^16.9.0", | ||
"stylelint-config-clean-order": "^6.1.0", | ||
"stylelint-config-standard": "^36.0.1", | ||
"stylelint-prettier": "^5.0.2", | ||
"typescript": "^5.6.2", | ||
"webpack": "^5.92.0", | ||
"webpack-cli": "^5.1.4", | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,6 +1,6 @@ | ||
.menu-bar { | ||
display: flex; | ||
flex-direction: row; | ||
height: var(--ylv-status-bar-height); | ||
align-items: center; | ||
height: var(--ylv-status-bar-height); | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,12 +1,14 @@ | ||
.status-bar { | ||
align-items: center; | ||
position: absolute; | ||
bottom: 0; | ||
|
||
display: flex; | ||
position: absolute; | ||
align-items: center; | ||
|
||
width: 100%; | ||
} | ||
|
||
.status-message { | ||
padding-left: 8px; | ||
flex-grow: 1; | ||
padding-left: 8px; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm happy to do this or just use the string formatter... I dont mind looking at logs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure. I think we can add the problem matcher for the
string
formatter in another PR soon.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Before I make the changes let's take a look at the approaches we can take:
PROS: We can view the errors in a nicely formatted way and we can have the errors annotated inline by GitHub.
CONS: setting up custom stuff takes time; we might not want to use custom stuff given they might not always be compatible with the tooling upgrades / GitHub workflow, which means we might not want to maintain it as a long term solution.
string
formatter.PROS: It's the default formatter which means it should have the best support from the tooling contributors.
CONS: We lose the ability to have the errors annotated inline (until we move the files into the project root). It outputs relative paths, but GitHub workflow problem matchers only resolves paths from the project root. Supposedly we can check in the problem matcher, which currently does nothing, in the same PR to save another PR, but it's hard to verify if things would actually work. If we spot any issues after we move the log-viewer files, we might still need to fix in the PR we move the files or another PR.
github
formatter.PROS: We don't need any custom plugin to get the GitHub annotation working.
CONS: We will see a deprecated warning in the workflow results. We're using a deprecated but not yet removed formatter. If we don't upgrade the Stylelint version the formatter should still be there, and it's less likely we would upgrade it before we move the new-log-viewer files and migrate to the problem matcher approach.
I still think Approach 3 gives us the most benefits, but all CONs are minor since we might always need another PR to improve the lint experience after we move the new-log-viewer files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay i think it dosen't matter so much as we are going to move soon anyways. I am okay with 3.
Do you like this by any chance? This way we still preserve normal formatting when running locally (i.e. run lint:check locally and lint:ci for workflow)
"lint:ci": "npm-run-all --sequential --continue-on-error lint:check:js \"lint:check:css -- --formatter github\""
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you would need to modify workflow to use lint:ci