Additional scaffolding flavors for CoffeeScript, SaSS, SCSS

[benmgreene]

Love what you're building here, keep up the great work.

[cmather]

Thanks @benmgreene! Would love to have support for coffeescript, sass and scss. Any time to chip in? I don't have a great pattern for this but I did add support for less by just checking if the less package is installed.

https://github.com/EventedMind/em/blob/master/lib/generators/view.js#L22

[benmgreene]

I think the package-check approach could definitely work for CoffeeScript, but Sass/SCSS is a bit harder... the Sass package is very broken right now. Of course with regards to SCSS, all it really would do is change the files ending, so nothing would be much easier than that!

I'd definitely like to contribute a bit -- time is obviously in short supply, but I will endeavor to find some :-).

[jshimko]

On a somewhat related note, it'd be great to have the option of not create stylesheets at all when generating scaffolding/views (something like the "--no-stylesheets" flag from Rails). I use scss and I keep all those files in "client/sass/" with a more traditional stylesheet folder/file organization. I organize my styles based on functionality or general page location (ie header, footer, etc) rather than having a file for every view template.

For example, I have a main.scss in the root of my sass folder that is used as a manifest that imports all of the rest of the files as partials (with the partials containing a preceding underscore in their filename to avoid separate compilation).

File/folder structure like:

client/sass/_functions.scss       // sass functions
client/sass/_mixins.scss          // sass mixins
client/sass/_settings.scss        // For project-wide variables, settings, etc. 
client/sass/modules/_buttons.scss
client/sass/modules/_forms.scss
client/sass/partials/_header.scss
client/sass/partials/_footer.scss

And then my client/sass/main.scss would look like:

@import functions,
        mixins,
        settings,
        modules/buttons,
        modules/forms,
        partials/header,
        partials/footer;

The manifest approach gives me a really easy way to stay organized and to manage what is included in the final output from a single location.

I realize the stylesheet structure I use isn't necessary in Meteor, but I find it to be much easier to stay organized than the stylesheets all over the place approach that is somewhat common for Meteor apps. I find that it also simplifies setups that use sass functionality like variables, mixins, etc across the entire project.

Since I'm sure that creating em generator options for everyone's personal preferences isn't exactly a trivial task, I figured that having a way to exclude certain files based on a flag might be a useful option that wouldn't be too time consuming to add. What do you think?

Thanks for the great tool Chris. It's a huge time saver for my workflow.

[cmather]

Hey @jshimko, Thanks for the use case! Seems like a --no-<resource> flag would be a good idea in general.

[bobmonsour]

I would like to echo @jshimko on the idea of a no-stylesheets flag for em. I am using less with Bootstrap and have a similar setup that he describes. I don't plan on populating the less files that em generates. I use a stylesheet organization that is very similar to what he describes, i.e., using a main with a series of imports.

[chrisbutler]

+1 for centralized scss/sass... and i'd definitely be wiling to put some time in if we can come up with a clean implementation plan that works for everyone

em is an awesome initiative in general and i'd love to start using it asap

[afuggini]

+1 to the --no-<resource> flag.

[cmather]

Someone willing to take it on? I can help with design and reviewing code or even just where to start.

[jshimko]

I'd definitely be willing to put some time into this. It's something I would use regularly. I can obviously sift through the code to figure it out, but anything you can suggest to point me in the right direction would be a huge help. Thanks Chris!

[cmather]

Thanks @jshimko! Take a look at lib/generators/view.js. A few things to note:

• Options like --no-resource are passed in as a second parameter to your generator function. (args, opts).
• You can see the alternateExtensions mapping where I map from .css to .less if the less package is installed. Not very robust, but it works for now. Designs welcome! I only ask that we favor clarity over trickiness.
• Currently we have an each loop over html js and css extensions. Instead of doing a loop, we probably want to handle each separately. And only handle it if the --no- is not defined.

On the issue of whether to centralize the stylesheets as a standard practice. I wonder if we could have a few options for setting up your project structure. This would require that we have an em file in the project (maybe a .em folder with a config file in it). So one of the options might be where the stylesheets go. Or maybe we just provide different project structures all together. This would let people define their own if they want.

I would also love to see the ability to use packages to extend the em command line tool, either with additional project layouts or other useful sub commands. But I admit this is a bit trickier :). It's on my list of things to investigate.

Let's do devel work on the devel branch and keep master for releases.

[scottmcpherson]

I'll be happy to chip in on this. I also have a couple of other ideas that might be worth consideration.

[scottmcpherson]

I just submitted a pull request regarding this issue. A couple of things to note with this PR:

• you can include/exclude css, less, stylus, or sass using the --cssresource, and
  --no-cssresource flags with the following keywords: css, less, sass, scss, styl, stylus
• if you use the --no-css flag, it doesn't matter if you're using a preprocessor, no .csstype file will be generated

I like the idea of having a .em folder with a config file in it @cmather. It could get a little redundant typing in --no-resource every time you want to generate a view without css. Plus it would be pretty easy to map, for example, css config options into the commands and generators. Maybe a format like this:

{
   "globals": {
      "tabLength": 3 // this might take some work..
   },
   "views": {
      "pathFormat": "views/view_name/view_name.*",
      "css": {
         "create": true,
         "alternative": "less"
      },
      "js": {
         "create": true,
         "alternative": "coffeescript"
      }
   }
}

[cmather]

Oh cool @scott-mcpherson! I'll try to set aside some time tomorrow to take a closer look.

[gabrielhpugliese]

Hey guys,

I've changed the code to use stylus and coffee. It's in my branch:
https://github.com/gabrielhpugliese/em/tree/coffee

It does not have all options you talked about, but it seems to work.
PS: If you test it, please post your feedback!

[gabrielhpugliese]

FYI, I've went to a Hackathon this weekend and 4 people used my branch coffee without any problems. Today I've received a PR because I haven't added less on the branch.
Should I PR it @cmather ?

[cmather]

Yeah let's see a PR. How does it compare with the work Scott was doing?

[gabrielhpugliese]

I've done something very simple and automatic. If you have the package coffeescript it will create coffee files. Only that.

[scottmcpherson]

I have a somewhat flexible solution for this. I'd like to get this conversation going again and help get this feature added in. Can you guys check out this branch and let me know what you think. Instead of writing a few paragraphs about the features of this branch, I added an animated gif to illustrate them on the readme.md.
There's still some work to do on it, but let me know what you guys think.

https://github.com/scott-mcpherson/em/tree/config

@gabrielhpugliese It looks like we're both working on similar things. If your interested and have time, maybe we can work together on this.

[bobmonsour]

@scott-mcpherson I like it!

[scottmcpherson]

CoffeeScript is now being correctly rendered into the views.
https://github.com/scott-mcpherson/em/tree/config

[JamesLefrere]

@scott-mcpherson Fantastic work!

[scottmcpherson]

@JamesLefrere Thanks! I'd like to add more options in the .em/config.json to give the user more control over the way resources are generated. I'm open for suggestions if anybody has any and, of course, contributions are welcome.

[afuggini]

@scott-mcpherson @cmather maybe this is off-topic but I would add a set of default packages and maybe also account hooks to the initial set of files. I've seen that Iron Router is required but not added by default. This sounds like it should be a default.
I wonder how all this could be configured through config.json as well.
Anyone else thinks this would be useful?

[scottmcpherson]

@afuggini I agree, it would be nice to add some packages and maybe some hooks by setting some options in the config file, or possibly by default. One thing @cmather and I were talking about doing is possibly creating a master config file with options similar to what your suggesting.

Maybe the way it would work is that when em init was ran from within projects, the projects would sort of be set up and structured based off of the options set in the master config file, if that makes sense.

But yeah, this discussion probably deserves it's own "issue". Maybe we'll start a new discussion under milestones->Ideas and Design for this.

[afuggini]

Awesome idea. I started a new issue at #32, let's discuss!

[gabrielhpugliese]

@scott-mcpherson I've tested your PR and your idea must be improved just a little now.
When I ran em:init it created all files with the default extension. But I wanted to start a repo with coffee + stylus + jade. There is something I can do now except deleting everything and do the command again with the proper packages?

[scottmcpherson]

@gabrielhpugliese I agree with you 100%: there needs to be a way to set defaults when running em init. It's worth mentioning that If you run em init with coffee + stylus + jade already installed, the files that are generated will be created with those extensions. But it's probably more common/intuitive to first init the project, then add the packages. So there definitely needs to be some type of config arguments/flags.

[mariomelo]

What about a npm release with this new and awesome coffeescript support? 😉

[scottmcpherson]

@mariomelo 0.1.6 has been released and is now available on npm. It includes coffeeScript, css preprocessor, and different template engine support.

[mariomelo]

Amazing!

Thanks, scott!

[mariomelo]

It seems it isn't working properly. I added the coffeescript package and ran em init but it keeps generating .js files. Am I missing something?