Developer Experience Improvements: remix-cli-extras

[mphill]

Hello,

I noticed for things like session, cookies, creating routes - it all must be done manually if you aren't using a stack (i.e. indie stack).

I'm curious - does the core team for remix think they will go the batteries included path? If so then perhaps with a cli tool that has various generators or helpers. This would allow a more modular approach to the "stacks" and eventually the stacks could use this to provision the app.

i.e.

foo@bar:~$ yarn add-page
Enter the full path to the new page: /users/new
Include loader (Yn): y
Include action (Yn): y
 Creating  routes/users/new.tsx

foo@bar:~$ yarn add-auth
Enter authentication stategy (cookie, jwt, sso): cookie
 Creating sessions.server.ts
Add a login page (Yn):
 Creating routes/login.tsx
 Creating models/users.server.ts

foo@bar:~$ yarn add-db
Enter db backend (sqlite,mysql, postgresql): sqlite
 Installing prisma
 Creating utils/db.ts
 Creating config/db.ts

foo@bar:~$ yarn add-queue
Enter backend (bullmq, awssqs): bullmq
 Installing bullmq
 Creating utils/queue.ts
 Creating config/queue.ts

foo@bar:~$ yarn add-mail
Enter email  providers (sendgrid, mailgun): sendgrid
 Installing nodemailer
 Creating utils/mail.ts
 Creating config/mail.ts
 Creating templates/mail.welcome.ts

This is a dramatic oversimplification of the cli, but I hope it serves to illustrate the concept.

[cliffordfajardo]

The autogeneration of routes / files with actions loaders etc is easier if there the convention for creating files/routes etc was more contrained;
if you're your using a mixture of regular route folders or the upcoming flat routes convention #4483 - that will expand the problem space

@Kilian can probably weigh in better on that side of stuff; he's the creator & one of the leads for the flat routes feature
https://github.com/kiliman/rmx-cli

[Kilian]

You mean @kiliman, not me ;)

[kiliman]

LOL. Thanks!

[sergiodxa]

My only issue with this is that unless Remix decides the “best” library to do everything this can’t be done

For example, in the DB scenario, while Prisma is definitely one of the most popular options it doesn’t come bundled with Remix, by doing this Remix will say Prisma is the ORM you should use, but what happens if the team behind an app wants to use something else?

I think this makes more sense as generators inside a Stack, create a new app with some specific Stack and that stack can give you a command to run to generate more files based on the tech stack, so if you use it and the Stack comes with Prisma you know it will use Prisma for the DB instead of using something else, and you made this decision when you created the app

This will also allow other Stacks to use other options,for example a Cloudflare based Stack could use D1 as DB without Prisma.

[jackbravo]

Agreed. Like kysely seems to become increasingly popular, for example sst.dev using it as default instead of prisma.

Supporting two is hard. But has been done. For example, blitzjs.com has (had?) generators that allow to choose using formik/react-hook-form/react-final-form.

[AlemTuzlak]

I also do a lot of this in Remix Forge for you, and I plan to add all of the missing ones here, and because it's an extension it doesn't really make the Remix team tie the project to anything. Feel free to check it out here: https://marketplace.visualstudio.com/items?itemName=CodeForge.remix-forge

[mphill]

@AlemTuzlak Wow, great work and such a great approach. You're overlaying an IDE extension to replace the CLI generators. I kinda love it.

[AlemTuzlak]

Thank you! Means a lot, and also adding new features regularly and open to feature requests!