Feature: devbuild directory

[callumlocke]

(I already spoke to @addyosmani about this idea yesterday, and he seemed to like it, so I'm just entering it here to be tracked...)

I want a new command that works a bit like yeoman server, but instead of giving me an intermediate dev build via an HTTP server, it should give me that build as a live-updating directory, which I can then serve up using any third party server. (I'm calling this new directory devbuild for now – please could someone suggest a better name.)

NB:

• the temp directory doesn't serve this purpose, because it only contains compiled versions of Sass and Coffee files.
• the dist directory doesn't serve this purpose, because it is only updated when you run yeoman build, i.e. it doesn't "watch" app.

The devbuild directory would contain:

• All JS files – currently there is no single collection of all your JS files, as the ones compiled from .coffee exist only in temp/scripts, and the ones that originate as plain .js (such as vendor libs, and any modules that you choose to write as plain JS) can be found only in app/scripts.
• All CSS files – same again; currently these are split between temp/styles (for stuff compiled from Sass) and app/styles (for original plain CSS files).
• All HTML files (with the LiveReload snippet inserted) – currently not available anywhere as a file; it is only available as a generated HTTP response from the Yeoman dev server AFAIK. [1]
• All other files – currently they only exist in app. These should be copied over from app to devbuild whenever they change. Including manifest.json for Chrome apps/extensions, .htaccess, images, and anything else. (Although you could exclude .coffee and .scss/.sass files for the sake of tidiness.)

In other words, I'm asking for the exact same 'intermediate' build that you get from yeoman server, but rather than being dynamically assembled from various sources on the fly via the dev server, I want it to exist as a real live directory, automatically kept up to date with any changes made in app/**.

Things you could do if Yeoman had this feature...

• install devbuild as an unpacked extension/app in Chrome
• symlink to devbuild from your Apache web root, or any other server
• use some kind of sync service to watch devbuild and sync changes with a web host over FTP, so you can let others review the current state of your work quickly without building & deploying
• probably several other things

[1] There should also be the option not to inject the LiveReload snippet, as this can cause problems for some cases, e.g. you get console errors in Chrome packaged apps because they disallow writing to location.href (which is what the LiveReload script does). But even without LiveReload, it would still be really useful to be able to edit a file in app and then just refresh your extension/app without having to run yeoman build every time.

[sleeper]

I do like the idea !
I'm going to have a look at it !

[sleeper]

OK, as we're going to work on massive changes next week, we put this on the roadmap for 1.1

[callumlocke]

Awesome. Thank you.

Any idea of an ETA for 1.1? (Even if it's very approximate...)

[sindresorhus]

Should be pretty easy to do with the new system. We won't provide it by default, but we could have a wiki page on how to do it.

Basically; a duplicate of the livereload config, but instead triggers a full build, then we listen on files dist and it triggers the reload accordingly, or something.

[sindresorhus]

@sleeper still interested in doing this? if not could you unassign yourself so anyone else could have a go at it.

[robwierzbowski]

👍 for wiki page. This is an esoteric enough use case that I'd rather it not be in the default Gruntfile when I scaffold a webapp, etc.

[callumlocke]

I'm not sure I agree it's an esoteric use case. I think the ability to use any arbitrary web server software to serve your development app could open up loads of possible use cases that we haven't thought of yet.

But that aside, I also think this change could benefit the standard webapp use case, by simplifying the grunt config through separation of concerns. The "watch" config would only be responsible for watching files and running tasks, and the "connect" config would only be responsible for serving up a folder full of files. It's simpler. Currently, various tasks' configs have to be aware of the fact that resources are potentially distributed between .tmp and app (depending on whether they've had to be compiled or not, which IMO shouldn't be of concern to most tasks). Look through the Gruntfile and see how many times the .tmp/.app split needs to be 'explained' to different tasks in different ways... And it's not just task configs, but other things have to be aware of this split too (eg, <!-- build:js({app,.tmp}) -->). Personally I've found the split adds complexity when trying to integrate new tasks into a Yeoman project. It makes the development app a bit of a black box.

If we had one simple folder that contains a functioning development build of the app, it would be easier for people to integrate other tasks and external tools into the workflow. And the whole Gruntfile could get a bit less complex/brittle, with fewer conditions and caveats.

[robwierzbowski]

@callumlocke Those are good points. We'd have to add copy tasks for every file in the app folder to watch though, which would add complexity back in.

[callumlocke]

It's just one more copy target, matching all static files (basically the same as the existing copy:dist target, but going from app to .tmp). I don't think that's a big deal compared to all the benefits it could bring.

Then again it's a big change conceptually; it would have implications for other parts of the workflow (like the build and test tasks), so I understand if there's reluctance to do it now... If anything, I think it should be considered for the roadmap for webapp 1.0.

[sindresorhus]

Closing as there doesn't seem to be much interest in this.

I would fork one of our generators, implement your suggestion and prove its worth ;)