Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Gruntjs tasks #7

Closed
marcooliveira opened this issue Nov 14, 2012 · 8 comments
Closed

Support Gruntjs tasks #7

marcooliveira opened this issue Nov 14, 2012 · 8 comments
Assignees
Milestone

Comments

@marcooliveira
Copy link
Member

It would be great if Automaton also could take Gruntjs tasks. The goal here would be to achieve a state in which the user could invoke some grunt task just like any other autofile. From my understanding, Grunt tasks have a set of options as input, just like automaton. The main difference is that they have targets, while we simply invoke the task separate times, with separate options, if necessary.

This needs some proper planning before implementation, so if anyone wants to pick this, the first thing to do would be to discuss what you are planning to do.

@marcooliveira
Copy link
Member Author

This issue is related to #1.

@sindresorhus
Copy link

See gruntjs/grunt#497 and https://github.com/tkellen/node-task for how grunt tasks might end up in grunt 0.5

@marcooliveira
Copy link
Member Author

Thanks @sindresorhus! Will take a look at it as soon as possible. It would be great if we managed to get this done.

@ghost ghost assigned satazor Feb 8, 2013
satazor added a commit that referenced this issue Feb 9, 2013
satazor added a commit that referenced this issue Feb 9, 2013
satazor added a commit that referenced this issue Feb 9, 2013
@satazor
Copy link
Member

satazor commented Feb 9, 2013

Just wanted to share the implementation I engineered for this issue. After investigating, grunt wasn't made to be used programatically:

  • It calls process.exit, preventing others from taking control
  • It calls process.stdout.write and process.stdout.writeln instead of using events or streams to pass data

I could monkey patch process.exit and process.stdout or event grunt itself, but I would be messing with sensitive stuff in a process I don't own (remember that automaton has programmatic usage).
So I made a Runner that runs grunt tasks in a separate process (using fork). It's basically a queue of grunt tasks that are consumed by a worker (the fork). This approach has several advantages:

  • The necessary monkey patching is done in an isolated environment, preventing possible conflicts with other people's code.
  • Allows paralel execution of grunt tasks via multiple Runner instances
  • Allows better control of grunt itself

The Runner auto loads npm tasks automatically and allows to specify additional directories to load tasks from.
It's working great, will add tests later on.

satazor added a commit that referenced this issue Feb 10, 2013
satazor added a commit that referenced this issue Feb 10, 2013
- Process signals are only attached when necessary (and detached when possible)
- Remove the callback support for the run()
- Various bug fixes and improvements
@satazor
Copy link
Member

satazor commented Feb 10, 2013

It's done guys! :D

@satazor
Copy link
Member

satazor commented Feb 10, 2013

Upcoming changes to grunt will cause only the worker.js to change.

@marcooliveira
Copy link
Member Author

Just wanted to say that this is just awesome! 👍

@filipediasf
Copy link
Member

oh yeah :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants