mklabs / node-build-script

MIT License
322 stars 55 forks source link

mkdirs aborted: "Required task 'clean' missing" #50

Closed ghost closed 12 years ago

ghost commented 12 years ago

Hello.

I've trying to use the ideas of node-build-script to improve my js workflow, but I cannot manage grunt mkdirs to work.

It say that "clean" task is missing, but grunt clean works fine.

This is the important piece of my grunt.js file:

    exclude: '.git* build/** node_modules/** grunt.js package.json css/sass/'.split(' '),
    mkdirs: {
      staging: '<config:exclude>',
      output: '<config:exclude>'
    },
ghost commented 12 years ago

Ok. I've just realized that you are using fstream-ignore to manage mkdirs.

I've adapted the code to:

    mkdirs: {
      staging: 'app/',
      output: 'app/'
    },

and created a .buildignore with :

.git*

But the old problem (missing "clean" task) is still there.

mklabs commented 12 years ago

Hi Rafael,

I think grunt complains about a missing "clean" task, because the mkdirs tasks does specify a requirement on the clean task. eg. mkdirs task cannot be used without clean previously: https://github.com/h5bp/node-build-script/blob/master/tasks/misc.js#L17

You should be able to run: grunt clean mkdirs. grunt mkdirs alone will fail, due to missing clean task.

Indeed, we use fstream-ignore to do the groundwork of copying, it's very handy to be able to specify stuff we don't want to copy over the build dir, either via .gitignore or .buildignore.

Docs wasn't up to date for quite some time, but now it should mention fstream-ignore and the few ignore files involved in the process. exclude prop in grunt config is not used anymore.

I'll make sure to add a note on the necessity to run clean previously to the mkdirs task.

ghost commented 12 years ago

Oh. So that was the problem.

What is the correct complete workflow ?

grunt clean mkdirs concat css min rev usemin is correct ?

I don't see the publish folder after running it (only intermediate).

Additionaly, the rjs and copy commands have some standalone use cases, or is it just for internal use of node-build-script ?

Thanks Mickael.

mklabs commented 12 years ago

Seems like you're using the build-script as a grunt plugin.

https://github.com/h5bp/node-build-script/blob/master/tasks/h5bp.js#L35-55 is where a lot of complex code is to handle the build:* tasks. This may be changed in a near future, simpler is better.

You can probably use grunt build to trigger the whole build script (or maybe grunt build:default).

grunt clean mkdirs concat css min rev usemin is correct ?

You're not too far away. The default target is pretty much this: into clean mkdirs concat css min img rev usemin manifest copy time (manifest being a noop, time is just an helper to see how long it took to run the build).

Additionaly, the rjs and copy commands have some standalone use cases, or is it just for internal use of node-build-script ?

Probably designed for internal use at first, but I think they can also be used in standalone cases (and if not, we can slightly adjust them to be if there is need to)

ghost commented 12 years ago

Hey. Thanks.

This last post was really helpful to figure out a better approach.

Just one more thing:

Are you saying that the rjs task doesn't need to be manually configured ? (consider, for instance, this code: https://github.com/yeoman/yeoman.io/blob/master/Gruntfile.js#L161)

And, essentially, what should be the final difference between the intermediate and the publish folder in your design of node-build-script ?

Thanks

mklabs commented 12 years ago

Glad it was helpful.

Are you saying that the rjs task doesn't need to be manually configured ?

Nope, the rjs task still need to be configured, but I do think that how we integrate rjs optimization can be improved a lot. When using rjs, you have a lot of options, and in some case overlaps the concat / min tasks in place (when doing full project optimization with dir / appDir, against single file optim with name and out).

And, essentially, what should be the final difference between the intermediate and the publish folder in your design of node-build-script ?

Right now, they're pretty similar (btw, the output subtarget in mkdirs is not required).

The idea of staging directory (intermediate/) is that we do edit your files for optimization in a copy of your project to prevent the build script to touch your original files (like renaming all your assets to other files, with a hash of their content).

The output directory (publish/) is the result of the copy task basically. It just copies over the intermediate/ directory at the end of the process to a new directory, publish/. One thing you can do with the copy task and this output destination, is that you can configure the build script to create a single tarball of your final directory.

It's not super well documented, but you may find more information in the mkdirs doc page.

The task will "stream" the result of fstream.Ignore to dest, which might be a raw writable Stream, or a String in which case a new fstream.Writer is created automatically. If the dest string ends with .tar, then the copy is done by creating a new/single .tar file.

ghost commented 12 years ago

Once again, thanks.

Not only you provide a great tool, but also great explanation.

I'm closing this issue in order to reduce the noise in the track list. Thanks