Skip to content
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

Merged
merged 40 commits into from
Sep 18, 2024

Conversation

junhaoliao
Copy link
Collaborator

@junhaoliao junhaoliao commented Sep 11, 2024

References

new-log-viewer series: #45 #46 #48 #51 #52 #53 #54 #55 #56 #59 #60 #61 #62 #63

Description

  1. Add Stylelint config.
  2. Add Prettier config and integrate with Stylelint.
  3. Add npm script for linting.
  4. Set up CSS linting in the Github lint workflow.

Validation performed

Created test branch for testing PR submitting to main: junhaoliao#6

  1. With only CSS lint errors, only CSS lint errors got marked and the job has a failed status: https://github.com/junhaoliao/yscope-log-viewer/actions/runs/10803848528
  2. When the lint errors are fixed, the job passed: https://github.com/junhaoliao/yscope-log-viewer/actions/runs/10803951760
  3. With only ESLint lint errors, only ESLint errors got marked and the job has a failed status: https://github.com/junhaoliao/yscope-log-viewer/actions/runs/10803988196

… failed although the steps are continue on error.
@junhaoliao junhaoliao marked this pull request as ready for review September 11, 2024 02:39
new-log-viewer/package.json Outdated Show resolved Hide resolved
"lint:fix": "npm-run-all --sequential --continue-on-error lint:css-fix lint:js-fix",

"lint:css-check": "stylelint src/**/*.css",
"lint:css-ci": "npm run lint:css-check -- --formatter github",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did some internet sloothing and found they plan to remove completely [1] [2]
) and recommend to just use third party extension. I made that change in my suggestion in package.json. It also removed deprecation warning

@@ -29,4 +29,6 @@ jobs:
with:
node-version: 22
- run: "npm --prefix new-log-viewer/ clean-install"
- run: "npm --prefix new-log-viewer/ run lint:css-ci"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe just update this now to call lint:check:js and lint:check:css so lint:check dosen't run lint:css twice

@@ -29,4 +29,6 @@ jobs:
with:
node-version: 22
- run: "npm --prefix new-log-viewer/ clean-install"
- run: "npm --prefix new-log-viewer/ run lint:css-ci"
- run: "npm --prefix new-log-viewer/ run lint:check"
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry I think this was supposed to be lint:js-check.

Suggested change
- run: "npm --prefix new-log-viewer/ run lint:check"
- run: "npm --prefix new-log-viewer/ run lint:js-check"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you rid of this later anyways. so i'm ignoring

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah it turn out that no changes are needed in the workflow file after the scripts are simplified

"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\""
Copy link
Contributor

Choose a reason for hiding this comment

The 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

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the linters touch the same files

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

okay ltgm

@@ -29,4 +29,6 @@ jobs:
with:
node-version: 22
- run: "npm --prefix new-log-viewer/ clean-install"
- run: "npm --prefix new-log-viewer/ run lint:css-ci"
- run: "npm --prefix new-log-viewer/ run lint:check"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you rid of this later anyways. so i'm ignoring

"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",
Copy link
Contributor

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

Copy link
Collaborator Author

@junhaoliao junhaoliao Sep 18, 2024

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.

Copy link
Collaborator Author

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:

  1. Use a custom formatter in Stylelint and a custom action in the GitHub workflow.
    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.
  2. Use the default 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.
  3. Use the 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.

Copy link
Contributor

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\""

Copy link
Contributor

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

Copy link
Contributor

@davemarco davemarco left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Im good! Do you like for title "lint: Add support for CSS stylesheets in linting workflow."

@junhaoliao junhaoliao changed the title lint: Configure Stylelint and Prettier for CSS stylesheets and set up related GitHub workflow. lint: Add support for CSS stylesheets in linting workflow. Sep 18, 2024
@junhaoliao junhaoliao merged commit 9440832 into y-scope:main Sep 18, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants