New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scaffold an official project structure on with `meteor create` #6974

Closed
fandy opened this Issue May 4, 2016 · 40 comments

Comments

Projects
None yet
10 participants
@fandy

fandy commented May 4, 2016

Having a pre-defined folder structure solves the problem of having to create them manually. It also enforces good practices for beginners. Deleting the todo-app every time I start a new project is tedious.


Requirements:

  1. Update meteor create to take an argument --bare or --scaffold
  2. Create two new skeletons to correspond
  3. Bare skeleton should just have a package.json and .meteor directory
  4. Scaffold should have a directory structure of the form #6974 (comment)
  5. Ensure help is updated
@stubailo

This comment has been minimized.

Contributor

stubailo commented May 5, 2016

Right now we already have client and server, what should we add? imports with api, ui, startup, etc?

@fandy

This comment has been minimized.

fandy commented May 5, 2016

It might be something like this:

client/
server/
lib/
imports/
api/
startup/

Empty/ unused directories wouldn't be added to git since we're not using .gitkeep. It'll keep it nice and clean while providing a nice foundation to your application which you don't have to worry about creating.

@laosb

This comment has been minimized.

Collaborator

laosb commented May 6, 2016

Actually it's a problem of having a perfect production structure or having a good example to play with. I think we had discussed about it somewhere earlier but didn't come up with a solution. And now it comes again and we should have a solution now. @stubailo

@fandy

This comment has been minimized.

fandy commented May 6, 2016

This scaffolding woolly act as a guideline for those who'd benefit from it (which is vastly greater than the simple-todos example). You can always follow your own project structure as needed, just like simple-todos.

@laosb

This comment has been minimized.

Collaborator

laosb commented May 6, 2016

@fandy True. So what kind of structure is better as default? Something to play with the Meteor Magic or serious production? It makes differences.

@fandy

This comment has been minimized.

fandy commented May 6, 2016

@laosb an empty project structure doesn't bloat the app in any way, especially since unused directories aren't added to Git. This doesn't enforce opinions on Meteor but rather saves time when starting a new project.

@stubailo

This comment has been minimized.

Contributor

stubailo commented May 6, 2016

@tmeasday would we take a PR to add more folders to the starter app?

@tmeasday

This comment has been minimized.

Contributor

tmeasday commented May 6, 2016

We discussed this previously and it was a bit tricky because there's a tension between a good boilerplate and something simpler that you use for things like quick hacks / repros / demos.

I personally am an advocate for 3rd party boilerplates. @fandy - what files are you deleting from the skeleton when you create a new app?

@lorensr

This comment has been minimized.

Collaborator

lorensr commented May 6, 2016

What about:

  1. meteor create: basic. either current or maybe just a package.json (there have been a few times when making repros that i was annoyed at having to remove the client and server files. with repros you want the smallest amount of files/code – like a single server.js)
  2. meteor create --structured: follows the Guide structure http://guide.meteor.com/structure.html – maybe with files that have comments and import/export demonstrations, but not code for an actual app
@tmeasday

This comment has been minimized.

Contributor

tmeasday commented May 6, 2016

@tmeasday

This comment has been minimized.

Contributor

tmeasday commented May 6, 2016

(Btw I don't want to strip 1. down any further because of tutorials. I'd be open to meteor create --bare however)

@lorensr

This comment has been minimized.

Collaborator

lorensr commented May 6, 2016

How would 2. compare to https://themeteorchef.com/blog/introducing-base-v4-0-0/ ?

Base has a lot of actual code in it, like a login system, and picks react. I was thinking like this, but nothing inside the html and css files, and the only thing in js files are imports and/or comments on what the file is for:

image

Now that I look at Base, maybe 3 below could have other generally recommended & useful things like eslint and test packages and npm scripts.

  1. meteor create --bare (does this need the package.json?)
  2. meteor create
  3. meteor create --recommended-structure

I personally am an advocate for 3rd party boilerplates.

Downside is 99% of people won't find them. If we want to improve the avg dev who wants to start off a new project in the best recommended way, maybe she'll find the option in the docs and try it, and that will improve her life. I even think that it would be good to have a fourth option meteor create --with-react or --opinionated-structure that has more opinions, maybe just clones Base.

@tmeasday

This comment has been minimized.

Contributor

tmeasday commented May 6, 2016

I'm pretty convinced, if someone wants to take the time to do this. I can help walk through what's involved.

My question would be should we switch it to

  1. meteor create --bare [yes I do think we need a package.json]
  2. meteor create --simple [and change all the tutorials to do this]
  3. meteor create

On 4. I think let's start here and let that develop. We'd need maintainers that are committed to keeping these opinionated structures up to date which would be a bit of work.

@stubailo

This comment has been minimized.

Contributor

stubailo commented May 6, 2016

Hmm, what about the complex one being meteor scaffold? Then we can make it arbitrarily complex without being worried about meteor create.

@tmeasday

This comment has been minimized.

Contributor

tmeasday commented May 6, 2016

I'd prefer meteor create --scaffold so we aren't adding an extra command to the tool

@tmeasday

This comment has been minimized.

Contributor

tmeasday commented May 6, 2016

I updated the leading comment to describe the feature

@fandy

This comment has been minimized.

fandy commented May 9, 2016

I'm going to propose a PR for this with meteor create flags that scaffold different levels of complexity.

meteor create --bare (empty)
meteor create --simple (client/ server)
meteor create (full project structure)

@tmeasday

This comment has been minimized.

Contributor

tmeasday commented May 9, 2016

@fandy sounds great, but can we make it create --bare / create / create --scaffold (see description at the top) so that the new user flow is less intimidating?

@fandy

This comment has been minimized.

fandy commented May 9, 2016

@tmeasday should there be a prompt when meteor create is ran with no flags so users know about this feature?

@tmeasday

This comment has been minimized.

Contributor

tmeasday commented May 9, 2016

I guess that'd be good, but not required.

On Mon, 9 May 2016 at 14:46 Andy Fang notifications@github.com wrote:

@tmeasday https://github.com/tmeasday should there be a prompt when meteor
create is ran with no flags so users know about this feature?


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#6974 (comment)

@lorensr

This comment has been minimized.

Collaborator

lorensr commented May 9, 2016

Maybe "Generate scaffold? (y / n)" But that might subvert the goal of
making new user flow less intimidating, because I'd guess most new users
would choose the scaffold. Another option:

Would you like the simple directory structure or a full scaffold? ("simple"
/ "scaffold")

On Mon, May 9, 2016 at 6:23 PM, Tom Coleman notifications@github.com
wrote:

I guess that'd be good, but not required.

On Mon, 9 May 2016 at 14:46 Andy Fang notifications@github.com wrote:

@tmeasday https://github.com/tmeasday should there be a prompt when
meteor
create is ran with no flags so users know about this feature?


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#6974 (comment)


You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#6974 (comment)

@tmeasday

This comment has been minimized.

Contributor

tmeasday commented May 9, 2016

I think building a project from the scaffold is rare enough (how commonly
do you start a big project, after all?) that it doesn't need to be
super-easy

On Mon, 9 May 2016 at 15:36 Loren Sands-Ramshaw notifications@github.com
wrote:

Maybe "Generate scaffold? (y / n)" But that might subvert the goal of
making new user flow less intimidating, because I'd guess most new users
would choose the scaffold. Another option:

Would you like the simple directory structure or a full scaffold? ("simple"
/ "scaffold")

On Mon, May 9, 2016 at 6:23 PM, Tom Coleman notifications@github.com
wrote:

I guess that'd be good, but not required.

On Mon, 9 May 2016 at 14:46 Andy Fang notifications@github.com wrote:

@tmeasday https://github.com/tmeasday should there be a prompt when
meteor
create is ran with no flags so users know about this feature?


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#6974 (comment)


You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#6974 (comment)


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#6974 (comment)

@zol

This comment has been minimized.

Contributor

zol commented May 9, 2016

We've refrained from adding prompts to the tool so far so it's more easily scriptable. I would prefer to add copy to the hint text that you see after you run meteor create inviting you to try out running meteor create [--scaffold|--bare].

@lorensr

This comment has been minimized.

Collaborator

lorensr commented May 9, 2016

Oh yeah, I like that best!

On Monday, May 9, 2016, Zoltan Olah notifications@github.com wrote:

We've refrained from adding prompts to the tool so far so it's more easily
scriptable. I would prefer to add copy to the hint text that you see after
you run meteor create inviting you to try out the scaffolded app.


You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#6974 (comment)

@fandy

This comment has been minimized.

fandy commented May 11, 2016

@zol agreed, I'll work on a PR soon.

Will look something like this:
meteor create client/server
meteor create --bare empty
meteor create --full large project structure

When no flags are used Meteor will log a hint so users are aware of this feature.

@zol

This comment has been minimized.

Contributor

zol commented May 11, 2016

Great, thanks.

@lorensr

This comment has been minimized.

Collaborator

lorensr commented May 17, 2016

Here's another template that might be helpful, by @dburles https://github.com/dburles/meteor-guide-starter-react

@stubailo

This comment has been minimized.

Contributor

stubailo commented May 17, 2016

@tmeasday I was under the impression that the above labels are only for bugs?

@lorensr

This comment has been minimized.

Collaborator

lorensr commented May 17, 2016

Confirmed, according to issuetriage, is for both. For FRs it means that it's clear and can't be done as a package

@tmeasday

This comment has been minimized.

Contributor

tmeasday commented May 17, 2016

What @lorensr said

@ghost

This comment has been minimized.

ghost commented May 26, 2016

Another idea: Add the option of specifying view layer.
Could be done wither for the --bare or --scaffold ( I think only scaffold would make sense ).

For example:

meteor create --scaffold <ViewLayer>

<ViewLayer> one of: Blaze, React, Angular

I don't know if MDG gets stats about this stuff (from each time create is run), but it could be interesting to have an insight as to what view layer people are using. Could be overkill.

Could also have a mantra option

@zol

This comment has been minimized.

Contributor

zol commented May 27, 2016

@omgj feels like overkill but thanks for the suggestion.

@laosb

This comment has been minimized.

Collaborator

laosb commented Aug 8, 2016

Is there any final decisions? pull-requests-encouraged but how can people work on this

@fandy

This comment has been minimized.

fandy commented Aug 8, 2016

Turns out I don't have enough time these days to work on a pull, so I'll pass it up to someone else!

@laosb

This comment has been minimized.

Collaborator

laosb commented Aug 8, 2016

Never mind. For those who want to contribute, the final agreed solution was described there.

@mhidou

This comment has been minimized.

Contributor

mhidou commented Aug 21, 2016

I started to work on this issue I will soon publish a PR

@Batistleman

This comment has been minimized.

Batistleman commented Sep 9, 2016

Instead of adding this to meteor, how about creating a tool like this: https://github.com/Batistleman/mgb (just a POC)

Or does this already exist?

@tmeasday

This comment has been minimized.

Contributor

tmeasday commented Nov 8, 2016

#7807 is merged!

@tmeasday tmeasday closed this Nov 8, 2016

@cyclops24

This comment has been minimized.

cyclops24 commented Nov 13, 2016

Hi, I think @omgj suggestion also good. for example:
meteor create --scaffold <ViewLayer>
<ViewLayer> one of: Blaze, React, Angular

Because now I need remove html and js and add new React version.

@maka-io

This comment has been minimized.

maka-io commented Mar 15, 2018

@Batistleman You could try my scaffolding tool:
maka-cli

$ maka create react-app
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment