[Generators] generated code should be linted and formatted

[AntonioMeireles]

[Hi again!]

... either unconditionally, or at least as an option

All the best, and a great weekend!

[Tobbe]

Why do you need that? Isn't the code generated by the generators already in the correct format?
(Not saying it's a bad idea, just curious for more details 🙂)

[AntonioMeireles]

(replying from phone, so sorry in advance for brevity)

basically consistency. ideally whatever is built from generators should respect project's lint defaults (scope/context is this and what follows - #1381 (comment))

hope this helps.

have a great weekend

[Tobbe]

ideally whatever is built from generators should respect project's lint defaults

Agreed! IIRC we already do run everything we generate through prettier. I guess we could look at adding linting as well. But I'll let others chime in with their opinions as well

[jtoar]

@AntonioMeireles I think we should (and do) lint/format everything we generate, but that can happen in the framework as opposed to the redwood app, unless you meant you have different eslint/prettier settings that you want the generators to inherit?

[thedavidprice]

I think we should (and do) lint/format everything we generate

I do not believe this is this case. Quick search for lint in the package seems to confirm. Subjectively, I feel like I often end up with generated code that throws the red squiggles and re-formats on save.

Given confirmation, this gets a 👍 from me.

[macovedj]

Is there a list things that can be generated?

[thedavidprice]

+1 defaulting to running lint after generating (with option to disable)

@macovedj I just reference these directories within cli/generate:
https://github.com/redwoodjs/redwood/tree/main/packages/cli/src/commands/generate

Also this from the yarn rw g --help:

Commands:
  rw g types                 Generate supplementary code
  rw g cell <name>           Generate a cell component
  rw g component <name>      Generate a component
  rw g dataMigration <name>  Generate a data migration
  rw g function <name>       Generate a Function
  rw g layout <name>         Generate a layout component
  rw g page <name> [path]    Generate a page component
  rw g scaffold <model>      Generate Pages, SDL, and Services files based on a
                             given DB schema Model. Also accepts <path/model>
  rw g script <name>         Generate a command line script
  rw g sdl <model>           Generate a GraphQL schema and service component
                             based on a given DB schema Model
  rw g secret                Generates a secret key using a
                             cryptographically-secure source of entropy
  rw g service <name>        Generate a service component

Note: things like types and secret don't apply, but it also wouldn't hurt to run lint.

[macovedj]

Typically, I've seen config vary between members on teams, but config would be how you go about utilizing eslint or prettier or something similar right? As far as I know, neither of them expose utilities that would let you format something from within a script... which seems like something you would want/need here. Seems you would want to be able to call some utility that formats at the end of generation scripts. I'm still looking around the internet for exposed utilities, but wondering if this requires a home grown solution.

[thedavidprice]

@macovedj We already have default config for ESLint and Prettier. So what happens is that the generated code, using templates, sometimes doesn't conform to formatting, which means it immediately has a VS Code warning/error. This is annoying/confusing. What's more, it can't always be fixed within the template. E.g. sometimes a new import is needed — the generator just adds to the bottom of the existing imports but ESLint might get angry 'cause "not grouped correctly!".

The solution here is effectively to run:

• yarn rw g scaffold <model> (or any generator) followed by
• yarn rw lint --fix

However, it's probably not as easy as globally running lint --fix:

• we should consider whether or not it's OK to fix any/all pre-existing issues
• there are many cases where generator boilerplate has unused vars
• ... ?

🤷‍♂️

[orta]

Given that these errors seem to be mostly prettier errors as far as I've seen, this issue could be reduced in scope to be just prettier which can be guaranteed to avoid the potential for non-autofixable errors.

( Interesting, I read the source code, and found that templated files were ran through prettier )