Rethinking the current scaffolding architecture 🛠️

[DominusKelvin]

There is a need to rethink the current scaffolding in order to incorporate several features needed for The Boring JavaScript Stack.

Currently when a user runs npx create-sails <project-name>, the create-sails CLI uses an inline template to scaffold the project.

It more or less assembles the differences pieces that makes a Boring Stack app - Sails, your UI framework, even the necessary webpack config is assembled on demand.

The problem

While this is good and I argue rather simple, it might be a good idea to take a different approach to this. Because with this assembling setup, there is The Boring Stack app for Vue, React, or Svelte for one to look at.

The Solution?

What if there is are boring-vue, boring-react, and boring-svelte repositories, that when one runs npx create-sails <project-name> we first copy that specific repo and then whatever steps we need to take next happens.

What this will do is make contribution easy as contributors can focus on contributing to boring-vue, boring-react, boring-svelte respectively.

Granted this might lead to duplicate work and I think that's a good trade-off as the gains is easier collaboration.

[lennyAiko]

The idea of splitting each to their individual repo is a great one. It’ll make it easier for each framework to have its own features, more like each King having his own Kingdom to himself. And of course it’ll definitely enable more contributors to contribute to the stack they are most comfortable with. I say yes to more flexibility and easier development.

[DominusKelvin]

Yeah I think so too. Also might make it easier to integrate with Sails CLI in the future and have it call out to create-sails when one runs sails new <project-name --stack boring

[DominusKelvin]

Might be a good opportunity to have some DX on the CLI tooling. So for example one may be able to run npx create-sails <project-name> --boring(This defaults to the default scaffolding with Vue as the UI) or npx create-sails <project-name> --boring="react"

[Ndohjapan]

Selecting the framework from the npx create-sails is perfect.

However can you just highlight the importance of DX cause I am not quite familiar with it.

[lennyAiko]

DX is like the experience the developer gets when using your framework.

how easy it was to install and get started, was it straightforward, the interactivity with the command line and stuff like that.

And one of Kelvin’s aim is to improve DX when using the boring stack

[Ndohjapan]

More like Developer Experience same way we have User Experience (UX) right ?

[lennyAiko]

Exactly

[Ndohjapan]

Thanks I get it now

[DominusKelvin]

Plus this decouples the CLI from The Boring JavaScript Stack project starter scaffolds.

And as a contributor you can run the boring-vue, boring-react, etc projects as an application while you develop!

[DominusKelvin]

So I've had more thoughts about this and for a couple of reasons, a single repo may be the way to go. Having boring-vue, boring-react, etc, creates a lot of surface areas for issues and more moving parts.

Going a single repo keeps everything in the boring stack ecosystem in one place.

So contributors can clone this single repo locally and just cd vue for instance, run npm i and then sails l to start up the boring project.

What do you think @lennyAiko

[lennyAiko]

While this is a good idea, doesn’t this mean that that we are going to have 3 instance of sails? For each front end or can just one instance be used?

[DominusKelvin]

Yes we will and I think its a good trade off for a wholistic experience. create-sails will be rewritten to copy the vue, react, svelte directories.

It's a bit of repetition but the gain is contributors can cd into any of these boring stacks and just run sails l to get started

[lennyAiko]

Fair point. That means it needs to be as thin as possible. If possible only the necessities to run the stack successfully should be available.

[DominusKelvin]

Yeah of course, note, these are all files and they won't even up to MB(I think)

[lennyAiko]

Then I concur to this. This way contributors can even get the overall view of how it works in all Frontend frameworks. It goes well

[DominusKelvin]

Also gonna move the CLI, The Inertia Adapter for Sails onto this repo as well.

[lennyAiko]

Good idea, gives more chance to improve dx.

[DominusKelvin]

Yeah so everyone interested can see everything in a single repo. Also a labelling system should be in place

[lennyAiko]

What’s the idea for the labeling like?

[DominusKelvin]

Yeah since there are lots of tools in this ecosystem, when an issue is raised, there should be a recommended label as to what part the issue is for e.g create-sails, inertia-sails, vue, svelte, react, sails, etc

[lennyAiko]

I see. To more specific on what needs to be fixed. Then the list of labels can be added to the contribution.md, right?

[DominusKelvin]

Thinking about making those projects as git sub modules.

[lennyAiko]

If there will be no frequent changes then that’s a good idea

[DominusKelvin]

Yeah no need for this as it wasn't what I thought it was 😅

[Ndohjapan]

There is a need to rethink the current scaffolding in order to incorporate several features needed for The Boring JavaScript Stack.

Currently when a user runs npx create-sails <project-name>, the create-sails CLI uses an inline template to scaffold the project.

It more or less assembles the differences pieces that makes a Boring Stack app - Sails, your UI framework, even the necessary webpack config is assembled on demand.

The problem

While this is good and I argue rather simple, it might be a good idea to take a different approach to this. Because with this assembling setup, there is The Boring Stack app for Vue, React, or Svelte for one to look at.

The Solution?

What if there is are boring-vue, boring-react, and boring-svelte repositories, that when one runs npx create-sails <project-name> we first copy that specific repo and then whatever steps we need to take next happens.

What this will do is make contribution easy as contributors can focus on contributing to boring-vue, boring-react, boring-svelte respectively.

Granted this might lead to duplicate work and I think that's a good trade-off as the gains is easier collaboration.

Having them separately and boring would also help to enforce the same folder structure and make collaboration easier just as you mentioned.

[DominusKelvin]

Hey @lennyAiko what do you think? We have to revisit the folder structure again. Trying to setup the online version of The Boring Stack Starter templates on StackBlitz and then it hit me.

For one, I am of the opinion that those that want as little setup as possible should get it and also those that want like a robust app as well.

So if we reorganize and then have a templates subfolder with starter/vue/, starter/react/, etc. This may work.

What this does is enable us to have create-sails accept a --template flag that can match any future template we want the user to be able to scaffold with.

This doesn't break anything as running npx create-sails will use the starter template.

What do you think?

[lennyAiko]

I totally agree with the option of robust or not.

My thought is if you are implementing this, can it be specific in choosing what I am going for? If it would be possible to directly pick a template for Vue from the CLI. Something like:

npx create-sails -t --vue

And what is the journey of choosing a template going to look like? I have some thoughts to add once this is clear

[DominusKelvin]

The idea is to keep npx create-sails --vue or whatever still working and default to the starter template.

For now the plan is to move the current templates to templates/starter/vue for example.

I know that's more nesting but it keeps things organized for stuff like templates/boring-poll/vue for example.

And anyone can contribute templates following same convention