Repository navigation
GitHub Actions: Implement ESlint #1442
Description
Dependency
- Explore, document and make a new issue to implement linters which can be installed locally #2651
- after the spelling issues are done we can re-review this.
- Figure out which js files use liquid (and the least liquid in any file)
- Refactor a js file that uses liquid into two separate files
- Roll out plan for implementation
Overview
We need to implement a linter for our javascript code to standardize and maintain the code properly.
Action Items
- Create a list of possible bare minimum esLint settings that we can turn on
- During one of the developer meetings, discuss the possible settings with the team and finalize a list of settings to implement
- You may reference and use the list from this comment
- Implement a GitHub action that triggers on pull request or on push to the gh-pages branch
- The action should lint javascript files. The recommended tool for linting is Super Linter
- Create the action as part of your local fork of the repository
- Run the action on js files that should end in a success, and ensure that the action actually succeeds
- Run the action on js files that should end in a failure, and ensure that the action fails properly based on the correct settings
- Demo your prototype to the team and/or the technical lead to get approval
- After approval, create a PR for review
- Ensure that the linter does not trigger or break on liquid syntax
- For merge team: Release dependency on Create a wiki page for linters used by the HfLA website team #3230
- Update action items in the dependency issue if needed.
- If all dependencies in Create a wiki page for linters used by the HfLA website team #3230 have been resolved, remove the dependency label, move it to the new issue approval column and add a ready for milestone label.
Resources/Instructions
- A GitHub action for linting the scss files is already implemented, You may use that as reference when implementing this action for Javascript files.
- lint-scss.yml
- Issue for implementing scss lint: Implement SCSS lint #1441
- PR for implementing scss lint: Setting up GitHub Action for CSS and future linting #1957
- Recommended tool for linting: Super Linter
- Super Linter article
Activity
qiqicodes commentedon May 9, 2021
AmyMendelsohn commentedon May 10, 2021
averdin2 commentedon May 12, 2021
qiqicodes commentedon May 15, 2021
@averdin2 Can you let us know your progress in regards to this issue? Thank you =]
Progress:
Blockers:
averdin2 commentedon May 18, 2021
Es Lint Getting Started: https://eslint.org/docs/user-guide/getting-started
Es Lint Config: https://eslint.org/docs/user-guide/configuring/
Es Lint Rules: https://eslint.org/docs/rules/
wendywilhelm10 commentedon May 26, 2021
47 remaining items
ronaldpaek commentedon Jul 16, 2023
So I realize all these photos show prettier installed and, yes, prettier, was the last thing I was testing, and they play well with each other. I left just the prettier default setting because I know someone was ticking off every rule set if we know what rules to apply, I think it should be very fast to apply. but seeing as I was committing and pushing/saving files, I don't think the way I have it set up it will try to prettify the whole codebase.
I think some of the rules can be adjusted for prettier as we need. I think we can also adjust it to warn but still be able to make commits as well. Like this head tag thing for liquid/front matter, it doesn't know that that's not an HTML page.
I think this is useful; we can quickly see where inconsistencies are, and should be easy to fix.
I think if a codebase had single and double quotes switching back and forth, it could potentially stress new team members. I know it would stress me out, haha.
And in this example, I clicked a random js file, which already gives me a useful measure. About a variable that isn't defined, I think those things are super helpful on those big files I tend to get overwhelmed. 😆
ronaldpaek commentedon Jul 16, 2023
Lastly, my last task was to fix the liquid syntax, and actually, that was kind of the reason why I took on this task, but I guess all of this stuff is tied together. I'm not that detailed and organized, so I took a lot of videos and pictures and am reporting my findings.
I could not solve this issue yet, but I am thinking of reorganizing the liquid data, probably in a separate file. I'm just not 100% confident about how the data flows and is used, yet I still need to review the codebase some more.
Oh yes, I actually ended up creating a lot of config files. I wanted to mention I had to init the root folder to node so I could install things on the package.json.
I know I don't think I didn't it when I just did the linter for JS, but when I was looking into the pre-commit stuff since it's a front-end/client side thing, you need a package.json to be in the root, but I'm just reporting my findings I'm sure there is a better way, but at least we have some data, that this is all possible, and it can be done incrementally without breaking everything.
Okay, I am done with my report. 😄
@roslynwythe @t-will-gillis @blulady @ExperimentsInHonesty
ronaldpaek commentedon Jul 16, 2023
I hope not to sound like a salesman for linting and formatting software. But now I'll post more photos to convince us why we want this.
I think this is a good thing. Large codebases are intimidating, and it's worse if much of the code is not even. Being used, and if it is harder for new people to adopt the style we want, it will ultimately take longer to ramp up.
Clean Code = Happy Coder. It's like studying on a cluttered desk. 😆
I'd be willing to do all transferring/updating and 10000 commits to update every 1 week if you want ;)
ExperimentsInHonesty commentedon Oct 24, 2023
@ronaldpaek why did you unassign? Where should this issue be moved?
ExperimentsInHonesty commentedon May 7, 2024
Once this issue comes out of the icebox, This issue will need a really good read, and then a decision on what to do next by the dev lead.
ExperimentsInHonesty commentedon Jun 9, 2024