blueprints (formerly generators)

[stefanpenner]

• update existing generators blueprints to be idiomatic
• explore scaffolding
• tests
• allow projects to override of custom generator blueprint needs (ala rails generator templates)

see: #43

[stefanpenner]

@nathanhammond you mentioned "homework" this one, if you are interesting this one may be a good fit

[nathanhammond]

@stefanpenner I meant in terms of general beta testing. :) I'm trying to avoid volunteering for too much so I can spend more cycles on ember-flows-generator.

[jgwhite]

I’m going to put some time into this. If anyone wants to join forces, let me know.

[tonycoco]

I'd be willing to help @jgwhite

[jgwhite]

@tonycoco cool. I'm going to make a start on Sunday. Acceptance tests will be point of entry. Will be in #ember-cli :)

[jgwhite]

Is everyone happy to proceed with the current format for generated modules:

var FooController = Ember.Controller.extend({});

export default FooController;

Does anyone prefer the terser alternative?

export default Ember.Controller.extend({});

[jgwhite]

Couple of decisions after discussing with @rjackson:

1. We’re going to go with the terser style
2. The built-in generators will take their cues from those in ember-app-kit-rails

[eccegordo]

I am not sure what to call it but I am wondering if there is something between a full generator, and something more like a snippet generator that emits common ember code patterns. I would love to have a command along the lines of

ember g controller foo/bar --stub

That writes a file to

app/controllers/foo/bar.js

And stubs out a common dummy example of hypothetical controller. Ideally with a bunch of common stub code.

If not directly supported would be nice if ember cli had the ability to create your own snippets and stubs just by putting source files in a special directory.

The ember-app-kit-rails generators have been super awesome.

By way of example:

The above command could in theory create the file and push something like this inside:

export default Ember.Controller.extend({
  needs: ['foo'],

  myProperty: "bar value",

  cpBar: function() {
    var value = this.get('myProperty') + "bar";
    return value;
  }.property('myProperty'),

  actions: {
    handleAction: function(input){
      var message = "Hello " + input;
      this.send('prompt', message);
    },

    prompt: function(msg){
      alert(msg);
    }
  }

});

This may be hard to generalize but it would be nice if there was a way to store these common snippets and other custom shortcuts in an ember cli config folder somewhere. I am getting super lazy with my typing. :-)

Some of this can be be achieved via text editor commands e.g. "snippets" in sublime text. I started to build something for sublime text and EAK.
https://github.com/eccegordo/eak-sublime-text-snippets

But would love to have a small library of these from the ember cli prompt that were more file based in scope. Or multiple files.

[jgwhite]

@eccegordo what you describe is pretty much the goal. Great minds :)

Custom generators will live in a generators/ directory at the top level of the project. They’ll be made available automagically. You’ll also be able to override templates for the built-in generators using the same mechanism.

[MajorBreakfast]

Quick idea: Call generators stencils to avoid confusion with javascript generators? :)

[jgwhite]

@MajorBreakfast interesting thought. I like the term stencil a lot. Though we do already have blueprint. One counterpoint, generators are known and well understood concept for those familiar with Rails.

[MajorBreakfast]

@jgwhite ya, "blueprint" and "template" are taken. That's why I propose "stencil" :)

[stefanpenner]

Generate something based on a blueprint seems fine?

[MajorBreakfast]

@stefanpenner We already call the initial project structure "blueprint".

[rwjblue]

@MajorBreakfast - If you think about it these are the exact same thing. A "blueprint" is a number of files used as a template. Both the new "generators" (only used to explain what I mean) and the current blueprint/ directory conform to this definition.

The only change that I think we might need is to move blueprint/ to blueprints/init/ (or something like that).

[jgwhite]

@rjackson Agreed. Blueprints is nicely unambiguous and doesn’t conflict with any other naming conventions (generators, templates).

'ember-cli/blueprints/init' // blueprint for generating project
'ember-cli/blueprints/{controller,route,...}' // blueprints for generating application code
'my-app/blueprints/{foo,bar,baz}' // custom blueprints
'my-app/blueprints/{controller,route,...}' // custom blueprint overrides

[MajorBreakfast]

Hmm good point :) I like it.

I also like that both can be powered by the same logic.(Even the overwrite confirmation stuff)

@jgwhite What about

• ember-cli/blueprints/init/
  • blueprint.js
  • files/

The blueprint defined in blueprint.js could inherit from Blueprint like we currently do it with Commands and Tasks

[stefanpenner]

Yup and now that we have diffing it will be even nicer

[jgwhite]

Props to @mixonic

[tonycoco]

Just chiming in, instead of blueprint we could call it "bootstrap"... probably a bit more common.

[jgwhite]

@tonycoco personally I’d tend to think of “bootstrap” more as a verb. The terminology we seem to be settling upon is using “blueprints” to “generate” projects and files.

[MajorBreakfast]

@tonycoco I agree with @jgwhite, also I already associate "bootstrap" with the css framework.

[jgwhite]

@MajorBreakfast good point

[MajorBreakfast]

@stefanpenner I changed the issue title and description.

What verb do we use with "blueprint"? To "generate" a "blueprint" seems to imply the wrong thing. It's more like "use", "apply" (not good in js :), "employ" or "utilize". I'd keep ember generate <...>, though.

[jgwhite]

I think blueprint and generate work fine together. We’re generating files from blueprints, rather than generating blueprints.

[tonycoco]

I think that works, @jgwhite

[MajorBreakfast]

@jgwhite you're right. It's as simple as that.

[stefanpenner]

@jgwhite anything i can do to help you out on this?

[jgwhite]

@stefanpenner yes. I’d love everyone’s opinion on the acceptance tests and blueprints.

The task itself is a placeholder — I plan to write the real implementation following the remaining test TODOs.

[stefanpenner]

@jgwhite that looks rad. i skimmed the tests and didn't see:

generate model foo/bar covered, does that scenario work?

Also, it appears I can't open issues on that repo. Do you mind submitting a PR, it would make (even early) review + feedback easier.

[jgwhite]

@stefanpenner yup — turns out the existing blueprint.js handled it already without modification. The template test covers it, but can add more of these cases.

[stefanpenner]

@jgwhite perfect!

Thoughts on removing more default app/* folders as they will be added on-demand as generators are needed? The reasoning is to try and present something less intimidating.

[jgwhite]

@stefanpenner yeah, I was thinking the same. Be interested to get some newcomers’ perspectives on this. Is it more reassuring to see just the essentials, or a clear structure ready and waiting?

[stefanpenner]

@jgwhite essentials i think.

[jgwhite]

app
├── app.js
├── components
├── controllers
├── index.html
├── models
├── router.js
├── routes
│   └── index.js
├── styles
│   └── app.css
├── templates
│   └── application.hbs
└── views

or super-skinny?:

app
├── app.js
├── index.html
├── router.js
├── styles
│   └── app.css
└── templates
    └── application.hbs

[MajorBreakfast]

Essentials and I am for encouraging pods! Sorting by type isn't the most logical thing and we know it :)

[jgwhite]

@MajorBreakfast would be cool to re-ignite the discussion on discourse.

[jgwhite]

Also: I’m down with adding a service blueprint modelled after @tomdale’s proposal.

[stefanpenner]

@jgwhite I think I prefer the middle ground, although the super skinny might be nice as a community blueprint or something.

ember new --blueprint mini (or some URI to the mini blueprint) or something

[jgwhite]

@stefanpenner nice idea. We should add that to the roadmap.

[MajorBreakfast]

@jgwhite The resolver already supports pods, we just have to use 'em. We can't really discuss it further unless we have results that show how the current iteration works in practice.

[jgwhite]

@MajorBreakfast I’ve not tried them yet. How are you picturing the generator commands? Something like this?:

ember generate pod foo
ember generate controller pod:foo

Keen to discuss in more detail. I’m in #ember-cli if you wanna take the conversation there.

[MajorBreakfast]

A pods setting in the .ember-cli could determine the default.
ember generate controller foo

To force it:
ember generate controller foo --pods true
ember generate controller foo --pods false

[jgwhite]

So:

ember generate controller foo --pods true  => app/foo/controller.js
ember generate controller foo --pods false => app/controllers/foo.js

[stefanpenner]

singular pod flag

[jgwhite]

👍

[coderberry]

❤️

[stefanpenner]

tracking this now on #747