Redwood: TypeScript: Generators and Templates tracking issue

[thedavidprice]

_This is a sub-tracking issue of #234_

This is a component of Redwood's initiative to add first-class TypeScript support. 🎉

Generators are a part of the CLI package and located in this directory:
https://github.com/redwoodjs/redwood/tree/master/packages/cli/src/commands/generate

The CLI package is built with Yargs. Read more here.

Goal

The intention is to provide a path for a _collaborative, incremental_ transition to having 100% TypeScript generators. This means the scope of a PR can be an individual generator, which can be merged into the master branch on its own when it's ready.

• source templates will be .ts
• generators should be aware of both .ts and .js; this applies to 1) refusing to run if files already exist and 2) overwriting existing files using --force
  
  
  
  • In the case where existing files are a _different_ language target (e.g. in the case of a hybrid-project), the generator should refuse to run regardless of using the --force option; a clear explanation message should be given
  
  
• templates should be transpiled and formatted when the target language is JS (suggested to use ts.transpile and prettier, but this needs evaluation)
  
  
  
  • need to determine appropriate ts.ScriptTarget; "ESNext" seems like a candidate
  
  
  • ⚠️transpilation formatting goal == _match existing JS templates_ so that no updates are required for Redwood Tutorial, either code snippets or images (TBD as needed)
  
  
• generators should have CLI options for targeting --javascript or --typescript
  
  
  
  • generators should not _require_ a language target option; instead, the default target will be the project "language default" or a config override in redwood.toml if given.
  
  
  • Example: if tsconfig.json exists and there is no redwood.toml override, the generator will automatically set --typescript to true. Therefore, running yarn rw g [option] will target typescript.
  
  
  • TODO: create a new Internal package helper for easy access to this config value
  
  
• generators need to pass CI tests _and_ the generated ...test.ts|js files need to pass yarn rw test and yarn rw lint

Steps to Convert a Specific Generator

1. Rewrite each generator template, including template test file, as TS
   
   
   
   • TS files will _replace_ JS files
   
   
2. Convert corresponding __tests__ directory files and fixtures to TS
3. Add a JS and TS target CLI command option, e.g. [--javascript|--typescript] to each generator CLI command
   
   
   
   • commands should also be aliased [-js|-ts] respectively
   
   
   • set the behavior to automatically use the project "language default" (see above) OR a given --javascript or --typescript option
   
   
4. When language target=javascript, transpile and format TS templates to JS
5. do generated ..test.ts/js files pass yarn rw lint and yarn rw test?

Checklist: Templates and Generators

• [x] Destroy (New command in progress via #487)
  
  
  
  • [ ] confirm support for both ts and js filetypes, as well as hybrid Apps
  
  
  • [ ] add support as/if needed
  
  
• [ ] Helpers (PR #557 stalled out)
  
  
  
  • [ ] convert __tests__/helpers.test.js to TS
  
  
  • [ ] convert helpers.js to TS
  
  
• [ ] src/lib Files
  _note: these files are outside generators/_, but the functionality that relates to generators should be moved to src/commands/generators
  
  
  
  • [ ] src/lib/colors.js
  
  
  • [ ] src/lib/index.js
  
  
  • [ ] src/lib/test.js
  
  
• [x] Component #632
  
  
  
  • [x] convert templates/ files to TS
  
  
  • [x] convert __tests__/ fixtures and test.js to TS
  
  
  • [x] generator support for JS transpilation; enable --javascript as default
  
  
• [ ] Function
  
  
  
  • [ ] convert templates/ file to TS
  
  
  • [ ] convert __tests__/ fixtures and test.js to TS
  
  
  • [ ] generator support for JS transpilation; enable --javascript as default
  
  
• [ ] Layout #685
  
  
  
  • [ ] convert templates/ files to TS
  
  
  • [ ] convert __tests__/ fixtures and test.js to TS
  
  
  • [ ] generator support for JS transpilation; enable --javascript as default
  
  
• [ ] Page
  ⚠️ requires updates to Router to support TS
  
  
  
  • [ ] convert templates/ files to TS
  
  
  • [ ] convert __tests__/ fixtures and test.js to TS
  
  
  • [ ] generator support for JS transpilation; enable --javascript as default
  
  
• [x] SDL 👉PR #515
  
  
  
  • [x] convert templates/ file to TS
  
  
  • [x] convert __tests__/ fixtures and test.js to TS
  
  
  • [x] generator support for JS transpilation; enable --javascript as default
  
  
• [x] Service 👉PR #515
  
  
  
  • [x] convert templates/ files to TS
  
  
  • [x] convert __tests__/ fixtures and test.js to TS
  
  
  • [x] generator support for JS transpilation; enable --javascript as default
  
  
• [ ] Cell
  ⚠️ requires additional support to replicate functionality in TS. Details in this comment.
  
  
  
  • [ ] convert templates/ files to TS
  
  
  • [ ] convert __tests__/ fixtures and test.js to TS
  
  
  • [ ] generator support for JS transpilation; enable --javascript as default
  
  
• [ ] Scaffold
  ⚠️ requires SDL, Service, and Cells TS conversion
  ⚠️ requires updates to Router to support TS
  
  
  
  • [ ] convert templates/ files to TS: components, layouts, and pages
  
  
  • [ ] convert __tests__/ fixtures and test.js to TS
  
  
  • [ ] generator support for JS transpilation; enable --javascript as default
  
  

[jmreidy]

I've picked up SDL and Service, will post in the forum for volunteers for the rest!

[MarkPollmann]

I would start with Helpers 😎

[jmreidy]

@MarkPollmann FYI I've extracted the functionality to transform generated TS into prettier-ified JS, you can take a look at my PR or just branch off it.

[kimadeline]

Hello hello, I'd like to pick up the Component work next week. It would be what's under packages/cli/src/commands/generate/component, right?

wait, it appears twice in the checklist 🤔

[cannikin]

@kimadeline That would be amazing, thank you! None of the core folks are TS experts so any help is greatly appreciated.

Looks like @thedavidprice already updated the list to remove that second reference—we do only have one component generator, honest!

[thedavidprice]

Hi @kimadeline! Grateful in advance for the help --> yes, please 🚀

For examples of implementation in progress, do check out the work on #515 and #557 (I'm behind on reviews but will make it a priority this weekend.)

It would be what's under packages/cli/src/commands/generate/component/, right?

^^ yes, indeed

wait, it appears twice in the checklist 🤔

^^ 'cause we are _super_ thorough around here... also double pleasure of checking off lists when done!

(great catch, thank you --> edited 😉)

[thedavidprice]

@peterp @kimadeline
Question about specific generator behavior from here:

generator refuses to run if files exist in the same language

^^ original idea was to have the generator refuse if _either_ language exists. But I proposed that without any discussion. I have no strong opinion either way other than to defer to what we think user will expect and either warn or refuse if generator behavior might be unanticipated. And to have all the generators behave the same.

Thoughts/recommendations? 1) refuse on either language 2) refuse on same language 3) middle path (e.g. warn)

[kimadeline]

I have no strong opinion either, mostly from lack of exposure to hybrid projects 🙈 I agree with your other points though, going with what users would expect and unifying generator behaviour.

Now, what do you think users would expect? 🤔