Yeoman 1.0 Released | Hacker News Reader

Yeoman 1.0 Released

yeoman.io

172 pointshswolff55 comments

I don't understand why people need all this. Setting up the boilerplate for a web app manually doesn't take any time at all and only needs to be done once so what is there to automate? Am I the only one still doing it the old school way? Please enlighten me.

Yeoman sets up boilerplates for many different kinds of applications, with many different kinds of requirements, and gives you all the tools you need to get started.

This can be as convenient as typing in "yo bootstrap" to set up a generic bootstrap site, to "yo phonegap-backbone" to set up a workflow for a backbone and phonegap application. It not only sets up the directory structures for you, it also manages requirements inside of your project from external parties, test environments, and gives you a nice little live-preview setup with grunt automatically.

For me, it takes a lot of that project setup time out of the way, so I can get started coding rather quickly.

I keep trying Yeoman every couple of versions but so far, it breaks A LOT. It (used?) to set things up in a way that was hard to move to it another backend like rails. Oh, and it breaks a lot.

So I still do most things the old school way. Then I'm done and writing code instead of trying to figure out why Yeoman is broken or the app it generates isn't loading.

That has been my experience too. But to be fair, half the breakages was Grunt, half was Yeoman. Then I figured that the tools I use (coffe, jade, stylus, Flask) all support live-reloading anyway so Yeoman was not useful for me. A simple 20 line bash/powershell script was enough.

Same here. I was going to use it for a recent Angular project, but was greeted with such an enormous list of warnings that I wasn't sure if my project was configured properly and didn't have time to investigate. So far I prefer initializing projects with Compass, then doing the rest manually. Open to checking this out again eventually, but I need more straightforward and reliable results.

Generators can be used for more than initial project scaffolding. Take the backbone[0] or ember[1] generators for models, views, templates, etc. that automatically generate the scaffolding work of creating dirs and files.

To get a the scaffolding for a backbone app, and the pieces of a "blog" MVC module:

    yo backbone # generates your application base and build workflow
    yo backbone:model blog
    yo backbone:collection blog
    yo backbone:router blog
    yo backbone:view blog
    grunt server

[0] https://github.com/yeoman/generator-backbone

[1] https://github.com/yeoman/generator-ember

Bower for package management. JS needs a better package manager for browser packages. (NPM is great for Node-style packages, but bower is becoming the defacto standard for distribution of browser packages.)

Why do you think npm can't be used for browser apps? I publish all my browser code on npm and then use it via browserify. That way I started to write a lot more code which works both in browser and in node.

Simple: Not all node packages work in the browser. It'd be great if I could just say "ok this package will work for the browser, period." Also, with a module format that the browser can use (ie ECMAscript 6)

I haven't understood the need for Bower either. If I want say jQuery or Angular I just go to their websites and copy the CDN url. I don't see the problem to be honest.

The need for something like Bower or Browserify comes when you have complicated projects with lots of dependencies, some more than one level deep.

For example, app A depends on library B which depends on library C. If C is jQuery and those are all the dependencies you have, it's fine; but when a project grows a little larger, you do want a proper system.

This is not an uncommon thing; modularizing an app or library into many small, independent parts is simply good practice.

Concrete example: Our company has a library which is currently monolithic and too big for its own repo, so it needs to be broken up into many different modules.

For this we have to have a dependency system because every module in the library needs to be able to say that it needs another module to run.

Plus, if you are developing an app that uses (a bunch of modules from) the library, you want to be able to work on the module code concurrently. Having to minify/package library code and copy it into the app every time you make a change is very inconvenient.

Plus, eventually you need to bundle a single file, eg. mylib.min.js, that combine all the modules. Also a chore without a dependency system. Might be fine for just isolated one case, gets stupidly annoying for the next project, and the next, and so on.

What I like about Browserify is that you just require libraries in your code where you need them, and that way all dependencies are expressed in code; whereas Bower has explicit metadata, separate from the code, which may get out of sync over time.

Well, I can see it being useful if you're already on the command line or if you have to set up a lot of different projects with different configurations.

From what I understood is:

For normal approach:

1. Google CDN jquery

2. Get the CDN link of jQuery

3. Add it to your template

For Yeoman/Bower:

1. bower install jquery

2. Get the link/path where bower installed jQuery

3. Add it to your template

I'm personally a big fan of component [1]. It acts a lot like NPM, but uses an actual Makefile behind the scenes (I always though Grunt was a tad ugly...).

[1] https://github.com/component/component

Duplicated:

https://news.ycombinator.com/item?id=6263380

This is great - I've been using Yeoman since the first 1.0rc, and have to say that the tool chain is excellent and covers all the main parts of development with ease. Easy to bootstrap a new project, intelligent defaults for code organization, testing and minification for production.

I haven't found anything else that comes close for solely front end dev work.

Yeoman is fantastic...I used it several months ago when deciding (foolishly, in retrospect) to learn both CoffeeScript and AngularJS at the same time while making an app. I had never put the effort into setting up grunt tasks manually...so working with automated building and testing were things I never had while developing with JS (which you can take to mean that my past work with JS has been mostly trivial).

Besides just being a great package overall, Yeoman really helped me appreciate how what seem like trivial niceties -- the speed of auto-build vs. stopping and restarting the local server and hitting Refresh -- can really make the difference between gradually losing interest because of the accumulation of small inconveniences and actually enjoying the development process enough to finish a project.

What resources can you recommend for learning AngularJS and CoffeeScript at the same time? I had the same inkling, and I'm intrigued that you found it foolish. Why is that?

Actually I need to write a blog post about this...it was "foolish" in that it was learning two kinds of worldviews at once (CoffeeScript vs JS and AngularJS vs. other frameworks) though since I wasn't doing it for a on-the-job project that I (or anyone else) would have to maintain, it wasn't "foolish" in the disastrous way :)

But now that I think more about it, doing both at once helped me with how I generally learn things, which is: copy example applications and go through the motions, and slowly experiment/break things until it all makes sense.

However, the problem with this is that if you kind-of-know something, you just mindlessly retype the code without getting much benefit. I kind-of-know MVC (or whatever Angular is) frameworks so to make things a challenge, I took the Todo/Hello-world Angular apps and re-wrote them in CoffeeScript. There was enough mental exercise there that my brain didn't atrophy from looking at Todo/Hello-world-level code, and at the same time, I got some practice with CoffeeScript.

I guess the main "resource" that made this possible was with Yeoman, which chirped at me everytime I screwed up in CoffeeScript (i.e. missed a whitespace) and made it easy, via TDD, to slowly construct an Angular app despite being incredibly confused with some of Angular's magic.

The livereload stuff is magical. Best use of WebSockets ever...

Love Yeoman. For the love of god, how do I create 'pretty permalink' (Jekyll Style) with it - "about.html" to create "/about/index.html"?

Nginx - just remap the urls. We run http://carrot.is (not meant to be a plug, just an example) served statically via nginx and the urls are "pretty". You can use a little statement like this in your nginx config:

if ( $uri !~ /index\.html$) { rewrite ^(/.+)\.html$ $scheme://$host$1 permanent; }

Offtopic - your username reminds me of a line from the Beverly HillBillies that went something like: "Hi, I'm Jethro Bodine; initials JB. Turn it around, BJ -- Boy Jenius." Ha ha.

+1 to jenius for a server-side solution but in addition:

Yeoman helps manage and coordinate various build tools, but for pretty permalinks on your production build, you're probably going to need something like a plugin for `grunt build` that renames files as they're copied into your /dist directory.

For development we use grunt-connect-rewrite. It is a middleware for connect (which yeoman uses) that allows you to write custom rules similarly to how you would implement them in Apache.

You can see our connect setup in this gist

https://gist.github.com/TheAlphaNerd/6322927

Is this for Node.js only? They keep saying 'web apps' but never explicitly that it's not. NPM is node, right? (sorry, not too familiar with Node)

Yeoman is purely development-time workflow tooling. It and its ecosystem (the "generator-XXXX" npm modules) use Node.js as the runtime on the development host. Typical Yeoman use would be 1) during development to speed dev, testing, etc., and 2) to build minified assets for deployment into production.

EDIT: Removed confusing "client-side" reference caught by 9oliYQjP -- thanks!

Actually, while client-side development is where it has gained the most popularity, I use some Yeoman generators for setting up some backends. Here is one such example that scaffolds a Node project: https://github.com/yeoman/generator-node. There's really nothing stopping you from using Yeoman for live reloading of a frontend and backend stack.

Ah, thanks!

Yeoman can be used on any project, not just Node.js ones. They have a lot of generators: http://yeoman.io/community-generators.html

Ahh, thanks much. Those generators are making it click.

    yo understand:now

Yes and yes.

EDIT: No and yes.

Your first "yes" is incorrect. Yeoman installs through npm and I imagine it runs on Node.js, but it can be used for many different projects: http://yeoman.io/community-generators.html

There are examples for CakePHP and Flask but none for Rails. Do you know of any? I have a simple traditional Rails which I am looking into porting to use Backbone and Rails as backend.

I just hope the generators API is now stable. I tried looking at the source of the various in-built generators to build a generator for BB10 apps, but every different generator was doing things in its own chaotic fashion. I got my generator somewhat working before future versions broke it.

Is there a changelog somewhere of what's added? One thing that's always frustrated me about this project is the lack of release notes on each new version.

I am sure this is good, but just how much it pulls down to do something basic is ridiculous:

  $ yo webapp
  $ npm ls | wc -l
  240

Nice. I see they reverted the ng-boilerplate-based generators for AngularJS though. Hopefully that gets put in again soon.

Is there a difference between 1.0 and 1.0.0-rc.1.1?

Can someone enlighten how is Yeoman vs grunt?

Yeoman uses grunt and sets up grunt for you in your new application.

does it work with latest node v0.10.17 ?

Yes.

Are you sure?

    $ node -v
    v0.10.17
    
    $ yo -v
    1.0.0
    
    # this works:
    $ yo webapp
    ...
    
    # this doesn't:
    $ yo
    ...
    fs.js:427
      return binding.open(pathModule._makeLong(path), stringToFlags(flags), mode);
                    ^
    TypeError: path must be a string
        at Object.fs.openSync (fs.js:427:18)
        at Object.fs.readFileSync (fs.js:284:15)
        at yoyo.Base.rootGeneratorName (/usr/local/lib/node_modules/yo/node_modules/yeoman-generator/lib/base.js:533:24)
        at yoyo.Base._setStorage (/usr/local/lib/node_modules/yo/node_modules/yeoman-generator/lib/base.js:542:34)
        at yoyo.Base (/usr/local/lib/node_modules/yo/node_modules/yeoman-generator/lib/base.js:85:8)
        at new yoyo (/usr/local/lib/node_modules/yo/bin/yoyo.js:12:18)
        at Environment.create (/usr/local/lib/node_modules/yo/node_modules/yeoman-generator/lib/env.js:366:10)
        at Environment.run (/usr/local/lib/node_modules/yo/node_modules/yeoman-generator/lib/env.js:409:24)
        at init (/usr/local/lib/node_modules/yo/bin/yo:97:7)
        at pre (/usr/local/lib/node_modules/yo/bin/yo:109:3)

Guessing here, but you might have some older, incompatible generators installed. Could you try to reinstall your global generators?

I wiped out all npm modules and reinstalled node. Still getting error. I installed yeoman using:

    sudo npm install -g yo generator-webapp grunt-contrib-compass

That shouldn't happen then. Would you mind opening an issue at https://github.com/yeoman/yo/issues about this?

For those following along at home, this issue is now tracked at:

https://github.com/yeoman/yo/issues/69

Resolved :) But it would be great if you could test to make sure it's fixed.

Should I be ashamed or proud that I believe in writing my own tools for my craft?

Depends if they're better or worse than Yeoman - I don't like to reinvent the wheel when Grunt etc is so flexible anyway. I like to write my own project-specific plugins for Grunt, though.

Where do you choose to draw the line for "writing my own tools"? Your text editor? Your JS engine? I like to think I choose the best tool for the job - if yours are better please let us know :-)

I used to like rolling my own stuff, but now I prefer leveraging excellent tools that allow me to more quickly and efficiently build, deploy, and maintain my projects.

Proud, good, smug, bad.

Reply on news.ycombinator.com