Closed PatOConnor43 closed 10 months ago
Hey there, I think resubmitting with the --fix disabled for now is probably a good idea-- especially since I just merged a couple smaller PRs that are causing merge conflicts as a result (sorry!)
Once that's in I can handle a change soon to turn the fix flag back on, resolve the errors myself (since the codebase is 99% my mess at this point), and usher in a new era of formatting.
I'm not too picky about JS specifics for now; until sometime this year I don't think I would have considered myself a JS dev either. I'm mostly interested in getting some sensible defaults in place that we can adapt as we go if we realize something compelling (or if an expert shows up to explain why we should be using something else). This is a useful start to that effect, imo, so thanks.
Hi @ckolderup I think this PR should be ready for review again. With this PR you can npm run lint
to see all the errors/warnings. I may follow-up with a Github Action PR later this week to get this running in CI if no one else gets to it.
This PR is meant to address some of what's required to add eslint. Including:
Things not covered in this PR:
npm run lint
that I think will require manual changes.~~I did have some questions though. Would you prefer that I make this PR smaller by not including any js file changes? (including removing the --fix flag from
lint
) OR Would you like me to take a shot at resolving the linting errors?~~The first option might be better just so I don't get added to the blame for all these files 😅I'm also not really a javascript dev. Most of my experience is with Go/Java/Rust, but hopefully this is close to what you were looking for. Thanks!