Consider "create-nava-app" CLI

[jcq]

Recommendation

A template like this is a prime use case for a command-line installer, a la create-next-app.

Why

This would bring multiple benefits:

• ability to use just the parts of the template that correspond to the needs of the project
• ability to provide multiple choices where there might not be a one-size-fits-all best option
• a user could run a globally accessible script to do the installation rather than needing to essentially clone the whole thing into a new repo

In regard to the multiple choices, I'm thinking of things such as:

• supporting vanilla JS as well as TypeScript (I'm open to not allowing this, and TS should certainly still be default, and a strong recommendation)
• supporting selection of CMS Design System (or similar common one) vs USWDS
• supporting different package managers from the installation step (yarn, pnpm, or npm)

How

Most modern similar systems utilize the Commander package for the CLI capabilities. This enables providing CLI flags and help text, which can be easily used to conditionally add optional packages, etc.

Prior art:

• create-next-app
• create-t3-app
• create-react-app — not really actively maintained, so I'd favor others

[lorenyu]

Great suggestion. There's currently a minimal command line installer that you can use to install the template into your repo via

curl https://raw.githubusercontent.com/navapbc/template-application-nextjs/main/template-only-bin/download-and-install-template.sh | bash -s

this is currently the recommended approach for installing the template and the one documented in the README.

Once there are more options I agree with you that having some sort of tool that prompts for choices could be a nice developer experience rather than requiring the developer to manually rip things out that they don't need.

Regarding the specific choices you suggested, I don't think we want to make those choices. I think typescript, uswds, and npm are solid defaults. I don't think yarn offers enough of an improvement over npm to really consider it, but I'll keep an open mind on it if you think otherwise.

[jcq]

Good points, all!

I'm totally on board with only keeping TS. 😁

In terms of the design systems, I know there are some common other ones that we will need to use depending on the agency for whom the project is being built. For instance, a Medicare project isn't going to be able to use USWDS; CMS will want us to use their DS (similar w/ VA.gov, etc etc). That said, I get wanting to establish good generic defaults, and USWDS should work for the majority of cases.

As for the package managers, that's a pretty common choice (and code for it could be lifted nearly verbatim from create-next-app) in these sort of template scripts. Yarn has fallen in favor recently with pnpm generally being considered the most performant default for new projects. NPM is fine (and should certainly still be available), but the caching and other benefits of the others can definitely improve DX for a team. That said, it's easy enough to switch afterwards; the benefit of having it establish it from the get-go means one doesn't have to remember to remove the package-lock.json file, etc