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

[Team] How can we help with existing projects. #1265

addyosmani opened this Issue Jan 10, 2014 · 3 comments


None yet
3 participants

addyosmani commented Jan 10, 2014

Brainstorming at this point.

Use case: You're a developer who has either (a) not setup Grunt for an existing project or (b) has setup a basic Gruntfile but would like to go further from there in a non-destructive manner.

  • Setup a Gruntfile if you don't already have one
  • Recommend improvements to your Gruntfile if you do have one (load-grunt-tasks, grunt-newer etc)
  • Setup performance optimization - JS, CSS, images (all optional)
  • Setup connect/server task if you don't already have gone
  • Setup a preprocessor if you don't have one
  • Maybe setup grunt-reduce for you
  • Performance benchmarking at build-time

This comment has been minimized.


hemanth commented Jan 13, 2014

We would be needing something similar to usemin but this operates on the Gruntfile if present and then generates a new Gruntfile with the optimizations mentioned above (after saving the old Grunfile) ?

Not sure if this is feasible, but it would be a nice challenge in trying to:

  • Parsing the Gruntfile and extracting the registered tasks and placing them in tasks dir.
  • Parsing the Gruntfile and extracting the configs and place them in the a related config dir.
  • Separation of concerns with something like loadConfig.

This comment has been minimized.


sindresorhus commented Jan 13, 2014

I think this is more of a documentation thing than an automation thing, at least for now. Good list though. Could maybe add some detection stuff.


This comment has been minimized.


addyosmani commented Mar 10, 2017

@yeoman 3 years later... :)

One useful idea that's come out of the CLI ecosystem over the last few years is the idea of "ejection". If a scaffolding tool abstracts away configuration to a point where you don't worry about it or edit it directly, it can be easier to patch that configuration over time with latest. The off-ramp is then ejecting config and handling everything yourself.

Taking this a step further, one could imagine a world where instead of working on scaffolding at a file level, we work on an AST level so after we've scaffolded your initial project we can more easily inject/patch changes without needing to worry as much about the structure of the file having changed. Unsure if other tools have already explored that idea.

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