Create script / CLI setup

[romansorin]

Mentioned in commit #40 — a script or CLI setup that cleanly takes care of the setup and configuration process could be useful and decrease the barrier to entry

[RyanWarner]

There's a lot to unpack here.

A great first step would be basic things like the name of your app, branding (colors, logo, favicon), Firebase config, etc. But we could (and should!) take it a lot further...

How do we go about selectively adding or removing features? For example, not every app needs Stripe. How do we yawnch add stripe? Or maybe it's something only done during project initialization. There could be a feature list that users could select from, and the project initializes appropriately.

[romansorin]

Good question with 'yawnch add' — I'd be interested in seeing how something like that can be built. For example, when working with Laravel you're able to use php artisan for a variety of commands and it takes a lot of setup and config out of the equation. I'll look into it and start building it up.

[RyanWarner]

🙌 Please document your research and progress here as you formulate a plan of attack.

[romansorin]

I thought about this a little bit more, mostly around the yawnch add idea — we could likely build out these configurations into separate npm modules so that yawnch add stripe would essentially just integrate Stripe into the project (which we would provide documentation on use), rather than dealing with some complex pipeline or API for choices.

Maybe at setup, we allow for the most barebones, default configuration, and all other extraneous things can be done following initialization of the project.

Publishing these modules under yawnch/{module_name} is an approach. Still need to write a bash script for the actual CLI tool, but I can do that.

Or, as many big packages do, there could be a global npm module under yawnch that would allow for this yawnch create functionality or something and go through the entire thing — all just ideation but that's something that excites me down the line.

[RyanWarner]

From an end-user perspective, I would love to allow users to pick their stack, and then click generate. Something similar to https://divjoy.com/ but without the layout editor (at least for now).

I think that adding some of the features after the fact would be quite difficult to achieve given that the directory structure and codebase, in general, could be wildly different after init.

[romansorin]

I think that our interpretations of this implementation differ a bit, which we can discuss in the sync later.

From what I'm reading, you're suggesting that the inclusion of these features or frameworks, libraries, etc., will be inserted directly into the project and its files. Intuitively I guess this makes the most sense and can technically allow for more configuration, but I find that there a few huge complications that arise with this method.

Regardless of the implementation, we have to ask: how can they easily and seamlessly pull these boilerplates or packages into their project, use them effectively, and get to their end goal. On the other hand, what if they want to remove these files? In theory, you could just remove these files in the same way that they were created, but people might want to restructure these files if they don't agree with it or there is a certain style they are adhering to. The script would then be extremely limited in this pruning and could result in conflicts. What if the user just wants to try out certain things but then remove it right after if it's not for them? It would be a huge burden to have to reset from scratch when it's so deeply engrained in the project itself.

I think for that the boilerplate itself – barebones, general/common structure, scripts and such – inserting directly into the project is the way to go because that's the foundation. The same method is good for UI components or choices that they want to pull in because those things are very opinionated and subject to large change.

IMO, I think the inclusion of things like Firebase, Analytics, etc., should be pulled in as separate packages for the people who would really like to just have something working, configurable, and frictionless. I take a lot of my inspiration in this idea from npm modules in general, but the Laravel approach of using PHP Artisan or Angular's CLI tool are awesome for this and really make it easy to use. You can pull in packages and simply reference it as needed, and default functions or routes can be overriden by user files.

This is a big wall of text so I'd like to talk about it more over a call, but keep this in mind. I'd love to show you tooling for these other frameworks and languages that we could absolutely utilize.

[romansorin]

https://oclif.io/docs/introduction

Looks like there's a non-bash approach, possibly. I'm going to load up this and start getting on it/playing with it.