Releases: yeoman/generator
v0.19.0
Towards yeoman-generator 1.0.0
This is our first deprecation release. This release is marking a bunch of now deprecated methods and their replacement.
All deprecated methods should still work as expected, but they'll print a deprecation warning in the console. Rely on these messages to find and replace deprecated methods you might be using in your generators.
If you're building a brand new generator, then you needn't worry.
To follow our deprecation policy, please join the discussion. (You can click the subscribe
button on the right toolbar to follow further discussions)
v0.18.10
v0.18.9
v0.18.8
v0.18.7
- Use the memory file-system inside the Gruntfile API
- Fix bug where custom generator description could be lost
- Improve debug logging (refer to readme for up to date documentation)
- Diffing module now support binary files (during conflicts)
Plus a general cleanup of core API and stricter usage of parameters.
v0.18.6
v0.18.5
Bug fixes
- Fix bug where selecting
skip
option during a conflict resolution was ignored (every files were written to disk)
Feature Updates
RunContext
now take asettings.tmpdir
boolean value. When set to false, it won't automatically run a generator inside a temporary directory. This feature is only provided to ease the upgrade of some generators; you really shouldn't ever need to use this option. If your test only pass on not cleaned up directory, this mean you have a coupling issue in your test and you're making them flakey. Please refer to http://yeoman.io/contributing/testing-guidelines.html for guidelines on how to keep your tests isolated.
v0.18.4
v0.18.3
Bug fixes
- Fix
helpers.mockPrompt
default value handling forconfirm
prompts Generator#template()
now correctly escape<%%= x %>
template notation. Note that it's probably best to start usingGenerator#fs.copyTpl()
.
Fixing events
Yeoman-generator have a very old event triggering system, and this was causing issues as it could triggers unexpected named events. This code have been cleaned up, it is not 100% backward compatible, but this is such an unused part of the code that we'll bump it in a patch version. Thing to know, now when running a generator, it'll trigger 3 kind of events:
run
(generator.run()
is called)method:<method name>
for each queue method running.end
(once the generator is done running)
For generator authors, don't use these events. The priority queue system is plenty enough to manage the life cycle of your generator. These events are used internally by our API, and might be useful for tools implementor (although I doubt it).