Open pantheredeye opened 2 years ago
Although we can't fix formatting errors ahead of time via templates (imagine a long file name that requires a line break whereas a shorter one would not), we can run yarn rw lint --fix anytime a generator is run (and also swallow the error output)
I don't think this is linting, right? That's formatting done by prettier.
So reading all the arguments above I would propose:
yarn rw lint
as part of our CI pipeline to make sure all generators produce files without linting issuesprettier
as part of the generators themselves to account for different variable name lengths etcOne thing we can't take into account here is the user's linting rules. We could have done that if we ran the linter as part of the generator. But we can probably use the user's prettier rules.
Just to outline what i'm thinking of:
Add yarn rw lint
(without --fix) to the right CI job(s) (guess only one or two them will do). This way the job will fail with an exit code of <> 0
and thus require to fix any existing code, as well as templates and code generators to only produce flawless code before something can be merged. As @pantheredeye said:
It feels cleaner to address linting issues before code ever hits the main branch.
This would also include removing --fix
from the fixture generation script (yarn build:test-project --rebuild-fixture
). That way we'd also get rid of an inconsistency, where the fixture code is automagically fixed, while the template code may still violate linting rules and thus look different, which does not feel correct.
BTW – we should also have the lint command include all {ts|tsx|js|jsx}*.template
-files.
Of course, new generators and templates would need to be tracked and included in the CI test scripts as they are implemented. Would be cool if we could come up with a configuration framework that shows which generator commands are already covered and which aren't, so new ones also make the CI pipeline fail unless they get included (i.e. into the smoke test pipeline).
This option surely requires a larger PR to get rid of each and every linting rule violation in code, templates and generated code first – but once in place we can finally ensure Redwood mainline always contains, respectively creates perfectly formatted, lint-flawless code.
Here is a (non-complete) list of issues that we would probably never have to deal with again once such checks are in place, b/c the offending code would never make it through the CI checks:
BTW – we should also have the lint command include all
{ts|tsx|js|jsx}*.template
-files.
Unfortunately I don't think that's feasible. A lot of them have a bunch of logic in them that makes the syntax invalid js/ts. For example https://github.com/redwoodjs/redwood/blob/main/packages/cli/src/commands/generate/sdl/templates/sdl.ts.template
@Philzen This is another one for your list I think https://github.com/redwoodjs/redwood/pull/6221 And please weigh in with your opinion on that one too, if you have one
Danny note:
If taking approach A.1: If lint fails during generate process, the generator will fail without giving a clear understanding of why. If this approach is taken, then we could swallow the error.
Summary
Should generated files be linted?
(This seems to get into the realm of: prettier vs linter and "... In other words, use Prettier for formatting and linters for catching bugs!".)
A) If so, what approach to take? We currently have two proposed paths forward for this option.
yarn rw lint --fix --path <file>
B) If not - what other approaches should be considered to clean up issues such as #1551, #6097 or #4824?
Motivation
Linting generated files has come up in different ways across multiple issues. A clear path has not been settled on and we are looking for consensus.
Option A (run
lint --fix
on generated files):1) The 'easy' way is to run
yarn rw lint --fix
on all generated files (with an option to disable). #6218 PR was filed this way to get something going. However, this slows down the cli and goes against #6027.2) Clean up inside the framework by running
yarn rw lint --fix
on generators in the CI pipeline. @Philzen proposed this with "If it doesn't come back with exit code 0, the pipeline fails and we have identified a todo 🎉" More detailed entry here: https://github.com/redwoodjs/redwood/pull/6059#issuecomment-1207528290.Personally, out of these two options, I like something along the lines of the second idea. It feels like good housekeeping to keep the framework clean vs pushing cleanup to the client.
Option B (other options):
Prettier seems to be the answer to the big whitespace issue, not lint. But, as @orta mentions, the files seem to go through prettier and there are still issues?
Originally posted by @cannikin in https://github.com/redwoodjs/redwood/issues/6097#issue-1324753803
Originally posted by @orta in https://github.com/redwoodjs/redwood/issues/1551#issuecomment-939868546
Detailed proposal
If Option A, what is the ideal solution, potential problems, gotchas, etc?
If Option B, what are other solutions or ideas?
Selected comments from previous discussions:
Originally posted by @jtoar in https://github.com/redwoodjs/redwood/issues/1551#issuecomment-845515064
Originally posted by @Philzen in https://github.com/redwoodjs/redwood/issues/6097#issuecomment-1207316225
Originally posted by @thedavidprice in https://github.com/redwoodjs/redwood/issues/4824#issuecomment-1074106957
Originally posted by @thedavidprice in https://github.com/redwoodjs/redwood/issues/1551#issuecomment-897309543
Originally posted by @Tobbe in https://github.com/redwoodjs/redwood/issues/6097#issuecomment-1202660817
Are you interested in working on this?