Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Grunt watch maintains context between triggered events #297

Closed
pghalliday opened this Issue · 15 comments

4 participants

@pghalliday

This has been a complicated problem to debug and I have fully described it in this blog post - http://stuffpetedoes.blogspot.nl/2012/07/nodeunit-mongoose-and-grunt-watch.html

In summary, when I use mongoose and have tests for my models I have to do some jiggery pokery to get the tests to run correctly when I update my mongoose model implementations.

If I follow the standard mongoose singleton pattern the changes are not used when running the tests as the singleton has never been unloaded between change events. I can see this being a problem with other libraries and patterns too.

Would it be possible to reset the Node.js context between each change event in the watch process? I imagine it might be possible to spawn a new node process for each event and solve this and other issues?

@pghalliday

Thought I'd share my new solution to this problem too. Again from my work creating a mocha task where I drop all modules from the require cache before running the tests

https://gist.github.com/3150484#file_mocha.js

@shama
Owner

This could be related to #237. grunt.file.clearRequireCache should be clearing the require cache but I don't think it always does with the watch task. FWIW, spawning child process tasks in the watch task is a good idea, imo.

@tkellen
Owner

We have a new watch task, which you can get by adding grunt-contrib-watch to your project deps and doing grunt.loadNpmTasks('grunt-contrib-watch') in your gruntfile. it should resolve this issue--if by chance it doesn't, can you please open the issue over on the watch task?

@tkellen tkellen closed this
@pghalliday

Cool, I'll give this a go - is this likely to get merged into the main grunt project and replace the builtin task? Or is there now a move away from builtin tasks?

@tkellen
Owner

Awesome. Grunt 0.4 will not ship with any built in tasks other than init. They're all in grunt-contrib-X now.

@pghalliday

Excellent, I shall look forward to it (this appeals to my sense of tidiness :))

@pghalliday

Just wondering if 0.4 will also support name spacing of tasks? I would imagine with the growing number of contrib and third party tasks, name collisions have the potential for becoming a real issue (or did I miss a feature that is already available?)

@tkellen
Owner

You can namespace your tasks now, just name 'em whatever you like :)

To that end, this is a good read:
npm/npm#798

@pghalliday

Ah, that's not what I meant. I was wondering about naming the tasks themselves as I load them. Much like we can with modules and require.

eg. I don't have to:

var fs = require('fs');

I could quite happily:

var filesystem = require('fs');

Then if i find myself wanting to use 2 different tasks that happen to have been given the same default name I can resolve it locally - in fact I would do away with default names. It would also be nice to be able to see when I look at a grunt file which module the tasks come from. At the moment I might only know If i dig around in the source.

In the npm case it's not possible for 2 packages to have the same name but for grunt tasks there is nothing to prevent this as the task names are not related to the package names. With npm people are forced to cooperate on naming (if needed) but with grunt tasks a name collision could occur and the first person to notice will be an end user who will get stuck (for the 5 minutes it takes for them figure out how to change the task names internally - but then they will have their own fork).

@tkellen
Owner

Ah. That's a fantastic idea. We have some pretty major changes in store for .5--that could definitely be a part of it.

@pghalliday

nice :)

@cowboy
Owner

FWIW, there's a grunt.renameTask method.

@cowboy
Owner

Also, using the --debug flag will output the full path to the file a task was loaded from, as it is run.

@pghalliday

Ok thanks, so i could rename an existing task before importing another set of tasks that would otherwise override it.

@cowboy
Owner

Exactly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.