Closed mkornatz closed 6 years ago
yo one-base:craft-3
or yo one-base:static-site
instead, and then each platform uses whatever generators it needs? Right now, the only thing helpful it's doing is setting up metadata about the project and initializing dotfiles. Both of these are pretty easy to do within each platform generator..gitignore
is generally framework-specific, I think that should be generated by the app generator, and same with .gitkeep
files.composer install
after setting up composer.json
eslint
, webpack
, jsmodule
, and jsrouter
generators.src/
), that should be handled by the app generator, because where those files live and the dependencies for them are managed in different ways depending on the framework.gulp
stuff, this is part of the build job for a given framework and should probably be specific to the app generator. For the case of something like Craft 2 vs 3. We could probably abstract it into a gulp-craft
generator and re-use it across those.App
I'm fine with that as long as we're not duplicating dot files in every sub generator. I think there are files we want in every project. The best example I can think of is for a .gitignore
(which might be part of the git generator but still)
I think there are things we want in every gitignore (like the macOS files) and then there are minor things we should add if craft3 (or whatever is selected). To me it just makes more sense from a mental modal to have the "trunk" and to add to it. That doesn't mean it's right, it's just how my brain was cutting this up.
I think if we want to run something like yo one-base:craft-3
or whatever, we should just make separate generators for each platform. Or use options yo one-base --craft3
instead. The sub generator syntax is a little confusing to me since running yo one-base
wouldn't do anything.
App. This generator doesn't feel necessary.
I think if you read through https://github.com/onedesign/generator-one-base/blob/master/generators/app/index.js its pretty clear that this base generator is doing a lot of work that is shared between every type of project. Just reading down the list of sub-commands:
.gitignore
src/
directories for scripts
and styles
which are needed across every project type.package.json
.env
README
That's not to say that these things couldn't all be handled redundantly and separately in each of the project type generators, just that the parent generator actually is doing a fair amount of heavy lifting that is shared among each of the project types.
@cmalven I think you have a point, but also highlights how intertwined everything is. Ideally you'd only want .gitignore
and .github
folder if you're creating a git project. You'd only want a .env
if you need it (typically Craft projects). You only want some of that package.json
info if it applies to the current project. I know that we use the same things 99% of the time, but I still like splitting them out for maintenance / testing reasons (right now it's hard for me to know which options are activated where).
Just a random side note: I'm thinking we should decide exactly what running just yo one-base
does. I'm thinking since 90% of our projects are Craft, use git, etc. It should run be an alias of something like:
- yo one-base:craft -v 3
- yo one-base:git
- yo one-base:odc|blendid
Also, I didn't meant to close the issue .
Totally understand that @cmalven and @brianjhanson and I agree we shouldn't be adding redundant code to the different platform generators. I suppose I'm kinda thinking to invert the structure so that craft2
, craft3
, static
, and static-nunjucks
would include parts of what currently is the app
generator. The reason for that is because not every project type will have some of these things. For instance, I expect to probably add a sailsjs
and rails
generator. In those cases, scripts/styles are handled differently, there may be no package.json
(Rails), .gitignore would differ
, js dependencies are installed differently, .env
will have different defaults, etc.
My thought is that we can break up the common stuff from what's currently in app
into stuff that's common across all projects vs. what's in some (or most) projects. So, it would do stuff like set up a base .gitignore
, create README.md
and LICENSE.md
, prompt for the common info (but maybe not store it in any particular format, because that could differ per framework).
Yeah, I hear what you guys are saying. The disconnect for me is that I never work on projects where the things the base generator does aren't needed. 100% of my projects include Git, a .env
file, a package.json
file, and an 80% identical .gitignore
and README
. So my opinion here probably isn't relevant.
These are @brianjhanson's thoughts:
There's been a bit of talk about what a V2 of the generator would look like, so I thought I'd start a thread here where we can discuss what it can / should be.
Here's kind of what I was thinking for the goals
Update to Yeoman 2
I think this is pretty self-explanatory, I believe there are a few breaking changes between 1.0.1 and 2.0.1
Split generator into smaller sub generators
I'm sure we could have a lot of long discussions about this, so here's where my head is at:
Main / App
Command
Thoughts This generator would be in charge of creating the
package.json
file as well as composing the sub generators. I'm not 100% sure we'd want to generate thepackage.json
or if we'd just want users to runnpm|yarn init
before running our generator. I kind of lean towards the latter (especially initially) but if we create it ourselves it would allow us to add an option (like--odc
or something) that would automatically fill out some information for us (mostly author name, author email, and author URL).Git
Command
Thoughts This would add some pretty minimal git stuff, creating a default
.gitignore
file, a.github
folder with aPULL_REQUEST_TEMPLATE
file and initializing git hooks. However, the git hooks could potentially be replaced by something like HuskyCraft
Command
Thoughts This would initialize the Craft side of things, either downloading and
.env
-ing Craft 2 or runningcomposer create-project
for Craft 3. This gets a little complicated at the moment since I believe Craft 3's create-project requires and empty folder. Not totally sure how this would work. This would also ask you about which plugins you want installed.Scripts
Command
Thoughts This is where things start to get even more complicated. I’m thinking this would do a few things: