Why the default template is not in the monorepo?

[mohsen1]

Having to coordinate changes between the core and default template can be tricky. Why the template is in a separate repo?

If it's for making it easier to download during redwood init, we can solve that with a GitHub Action that publishes a tarball from the monorepo that only includes the template for the init script to download.

[thedavidprice]

Looping in @peterp

Ah, conceptually I like where you are headed here. Why things are this way —> it’s due to 1) how yarn create works, e.g. runs an executable, along with 2) being able to easily understand and develop the App template — there are some historical setup/test/dev workflows that led to this setup. Based on your comment above, it seems you’re tracking with all this.

Indeed, local dev if painful at best. We discuss this internally quite often. And this topic is currently coming up a lot. Most recently with @RobertBroersma here in the Forums:
https://community.redwoodjs.com/t/guide-on-redwood-package-development/135/6?u=thedavid

I still think the way we want to handle this is via improved tooling. But could you take a look at the conversation in the forum and then put together a bit more on how this might work, e.g. handling the CRA template in the main monorepo via lerna/workspace.

[mohsen1]

For the end user it's totally possible to publish tarballs from the monorepo via GitHub Actions and replace this URL:

redwood/packages/create-redwood-app/src/create-redwood-app.js

Line 20 in 4d392e8

const RELEASE_URL =

For dev time I'm pretty sure it's possible to fix all the issues as others like create-react-app and next have their templates in mono rep.

I'm going to take a look into this for dev time and get back to you.

[peterp]

Hey @mohsen1,

The reason why the default template is in a separate repo is because I like the mental model of having a separate repo for what an actual redwood project would be when you create it. I find it easy to explore, reference and to make changes

When it comes to placing the template in the monorepo there are many duplicate files: .gitignore, README, babel.config.js, etc. that might make fuzzy matching/file jumping a bit more convoluted than usual. As an example, I want to change .gitignore and might not always consider that a monorepo would have more than 1 of those files and could change the incorrect one. Of course I would get used to this over time, but this is something that everyone who contributes would have to consider.

We also want to introduce different "create repos" that are user contributed in the future, and allowing users to specify the URL to a GitHub project (that they forked off of ours) seems like a natural way to enable that.

In terms of linking packages during development it appears that colocating the template into the monorepo wouldn't be any more advantageous, because yarn doesn't support nested workspaces.

Have you seen the new copy:watch command that was recently added to the redwood-tools command? I'm sure this will solve most of the linking issue of working on examples, templates, and projects whilst contributing to Redwood.

[peterp]

I've been thinking a lot about this issue, and it started making a bunch more sense to me when I started using TypeScript.

I think we should strongly consider this when we introduce the concept of sides.

[peterp]

This is closed by #1637