Grunt watch maintains context between triggered events #297

Closed
pghalliday opened this Issue Jul 18, 2012 · 15 comments

Comments

Projects
None yet
4 participants

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?

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

Owner

shama commented Sep 14, 2012

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.

Owner

tkellen commented Oct 15, 2012

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 closed this Oct 15, 2012

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?

Owner

tkellen commented Oct 17, 2012

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

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

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?)

Owner

tkellen commented Oct 17, 2012

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

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

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).

Owner

tkellen commented Oct 17, 2012

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

nice :)

Owner

cowboy commented Oct 18, 2012

FWIW, there's a grunt.renameTask method.

Owner

cowboy commented Oct 18, 2012

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

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

Owner

cowboy commented Oct 18, 2012

Exactly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment