diff --git a/app/authoring/composability.md b/app/authoring/composability.md
index 9878d774..6468adec 100644
--- a/app/authoring/composability.md
+++ b/app/authoring/composability.md
@@ -12,8 +12,8 @@ Yeoman offers multiple ways for generators to build upon common ground. There's
In Yeoman, composability can be initiated in two ways:
- * A generator can decide to compose itself with another generator (e.g., `generator-backbone` uses `generator-mocha`).
- * An end user may also initiate the composition (e.g., Simon wants to generate a Backbone project with SASS and Rails). Note: end user initiated composition is a planned feature and currently not available.
+- A generator can decide to compose itself with another generator (e.g., `generator-backbone` uses `generator-mocha`).
+- An end user may also initiate the composition (e.g., Simon wants to generate a Backbone project with SASS and Rails). Note: end user initiated composition is a planned feature and currently not available.
## `this.composeWith()`
@@ -25,13 +25,17 @@ When composing, don't forget about [the running context and the run loop](/autho
`composeWith` takes two parameters.
- 1. `generatorPath` - A full path pointing to the generator you want to compose with (usually using `require.resolve()`).
- 2. `options` - An Object containing options to pass to the composed generator once it runs.
+1. `generatorPath` - A full path pointing to the generator you want to compose with (usually using [`import.meta.resolve()`](https://nodejs.org/docs/latest-v20.x/api/esm.html#importmetaresolvespecifier) or poly fill with [import-meta-resolve](https://www.npmjs.com/package/import-meta-resolve)).
+2. `options` - An Object containing options to pass to the composed generator once it runs.
When composing with a `peerDependencies` generator:
```js
-this.composeWith(require.resolve('generator-bootstrap/generators/app'), {preprocessor: 'sass'});
+import { resolve } from "import-meta-resolve";
+
+this.composeWith(resolve("generator-bootstrap/generators/app"), {
+ preprocessor: "sass",
+});
```
`require.resolve()` returns the path from where Node.js would load the provided module.
@@ -41,7 +45,7 @@ Note: If you need to pass `arguments` to a Generator based on a version of `yeom
Even though it is not an encouraged practice, you can also pass a generator namespace to `composeWith`. In that case, Yeoman will try to find that generator installed as a `peerDependencies` or globally on the end user system.
```js
-this.composeWith('backbone:route', {rjs: true});
+this.composeWith("backbone:route", { rjs: true });
```
### composing with a Generator class
@@ -55,44 +59,46 @@ This will let you compose with generator classes defined in your project or impo
```js
// Import generator-node's main generator
-const NodeGenerator = require('generator-node/generators/app/index.js');
+import NodeGenerator from "generator-node/generators/app/index.js";
+import { resolve } from "import-meta-resolve";
// Compose with it
this.composeWith({
Generator: NodeGenerator,
- path: require.resolve('generator-node/generators/app')
+ path: resolve("generator-node/generators/app"),
});
```
### execution example
+
```js
// In my-generator/generators/turbo/index.js
-module.exports = class extends Generator {
+export default class extends Generator {
prompting() {
- this.log('prompting - turbo');
+ this.log("prompting - turbo");
}
writing() {
- this.log('writing - turbo');
+ this.log("writing - turbo");
}
-};
+}
// In my-generator/generators/electric/index.js
-module.exports = class extends Generator {
+export default class extends Generator {
prompting() {
- this.log('prompting - zap');
+ this.log("prompting - zap");
}
writing() {
- this.log('writing - zap');
+ this.log("writing - zap");
}
};
// In my-generator/generators/app/index.js
-module.exports = class extends Generator {
+export default class extends Generator {
initializing() {
- this.composeWith(require.resolve('../turbo'));
- this.composeWith(require.resolve('../electric'));
+ this.composeWith(resolve("../turbo"));
+ this.composeWith(resolve("../electric"));
}
};
```
@@ -117,18 +123,19 @@ which is composed of
## dependencies or peerDependencies
-*npm* allows three types of dependencies:
+_npm_ allows three types of dependencies:
+
+- `dependencies` get installed local to the generator. It is the best option to control the version of the dependency used. This is the preferred option.
+- `peerDependencies` get installed alongside the generator, as a sibling. For example, if `generator-backbone` declared `generator-gruntfile` as a peer dependency, the folder tree would look this way:
- * `dependencies` get installed local to the generator. It is the best option to control the version of the dependency used. This is the preferred option.
- * `peerDependencies` get installed alongside the generator, as a sibling. For example, if `generator-backbone` declared `generator-gruntfile` as a peer dependency, the folder tree would look this way:
+ ```
+ ├───generator-backbone/
+ └───generator-gruntfile/
+ ```
- ```
- ├───generator-backbone/
- └───generator-gruntfile/
- ```
- * `devDependencies` for testing and development utility. This is not needed here.
+- `devDependencies` for testing and development utility. This is not needed here.
-When using `peerDependencies`, be aware other modules may also need the requested module. Take care not to create version conflicts by requesting a specific version (or a narrow range of versions). Yeoman's recommendation with `peerDependencies` is to always request _higher or equal to (>=)_ or _any (*)_ available versions. For example:
+When using `peerDependencies`, be aware other modules may also need the requested module. Take care not to create version conflicts by requesting a specific version (or a narrow range of versions). Yeoman's recommendation with `peerDependencies` is to always request _higher or equal to (>=)_ or _any (\*)_ available versions. For example:
```json
{
diff --git a/app/authoring/dependencies.md b/app/authoring/dependencies.md
index 9c020cc0..f6c20658 100644
--- a/app/authoring/dependencies.md
+++ b/app/authoring/dependencies.md
@@ -36,7 +36,7 @@ on the command line in your project.
### Manage npm dependencies programmatically
-You can programatically create or extend your `package.json` file if you don’t want to use a template but like to have fixed versions of your dependencies. Yeomans file system tools can help you to get this job done.
+You can programmatically create or extend your `package.json` file if you don’t want to use a template but like to have fixed versions of your dependencies. Yeoman's file system tools can help you to get this job done.
Example defining `eslint` as dev dependency and `react` as dependency:
@@ -70,9 +70,9 @@ For example you want to install lodash as a dev dependency:
```js
generators.Base.extend({
- installingLodash: function() {
- this.yarnInstall(['lodash'], { 'dev': true });
- }
+ installingLodash: function () {
+ this.yarnInstall(["lodash"], { dev: true });
+ },
});
```
@@ -100,9 +100,9 @@ generators.Base.extend({
this.installDependencies({
npm: false,
bower: true,
- yarn: true
+ yarn: true,
});
- }
+ },
});
```
diff --git a/app/authoring/file-system.md b/app/authoring/file-system.md
index 17a0aa5b..20db5c6b 100644
--- a/app/authoring/file-system.md
+++ b/app/authoring/file-system.md
@@ -144,7 +144,7 @@ var beautify = require("gulp-beautify");
this.registerTransformStream(beautify({ indent_size: 2 }));
```
-Note that **every file of any type will be passed through this stream**. Make sure any transform stream will passthrough the files it doesn't support. Tools like [gulp-if](https://github.com/robrich/gulp-if) or [gulp-filter](https://github.com/sindresorhus/gulp-filter) will help filter invalid types and pass them through.
+Note that **every file of any type will be passed through this stream**. Make sure any transform stream will pass through the files it doesn't support. Tools like [gulp-if](https://github.com/robrich/gulp-if) or [gulp-filter](https://github.com/sindresorhus/gulp-filter) will help filter invalid types and pass them through.
You can basically use any _gulp_ plugins with the Yeoman transform stream to process generated files during the writing phase.
diff --git a/app/authoring/index.md b/app/authoring/index.md
index 6d54f9cc..7140610a 100644
--- a/app/authoring/index.md
+++ b/app/authoring/index.md
@@ -14,7 +14,6 @@ In reading this section, you'll learn how to create and distribute your own.
Note: We built a generator-generator to help users get started with their own generator. Feel free to use it to bootstrap your own generator once you understand the below concepts.
-
## Organizing your generators
### Setting up as a node module
@@ -30,12 +29,11 @@ Once inside your generator folder, create a `package.json` file. This file is a
"name": "generator-name",
"version": "0.1.0",
"description": "",
- "files": [
- "generators"
- ],
+ "type": "module",
+ "files": ["generators"],
"keywords": ["yeoman-generator"],
"dependencies": {
- "yeoman-generator": "^1.0.0"
+ "yeoman-generator": "^6.0.0"
}
}
```
@@ -85,29 +83,25 @@ If you use this second directory structure, make sure you point the `files` prop
```json
{
- "files": [
- "app",
- "router"
- ]
+ "files": ["app", "router"]
}
```
-
## Extending generator
Once you have this structure in place, it's time to write the actual generator.
-Yeoman offers a base generator which you can extend to implement your own behavior. This base generator will add most of the functionalities you'd expect to ease your task.
+Yeoman offers a base generator which you can extend to implement your own behaviour. This base generator will add most of the functionalities you'd expect to ease your task.
In the generator's index.js file, here's how you extend the base generator:
```js
-var Generator = require('yeoman-generator');
+import Generator from "yeoman-generator";
-module.exports = class extends Generator {};
+export default class extends Generator {}
```
-We assign the extended generator to `module.exports` to make it available to the ecosystem. This is how we [export modules in Node.js](https://nodejs.org/api/modules.html#modules_module_exports).
+We export the extended generator to make it available to the ecosystem. Node.js supports [ECMAScript modules](https://nodejs.org/api/esm.html#introduction).
### Overwriting the constructor
@@ -116,16 +110,18 @@ Some generator methods can only be called inside the `constructor` function. The
To override the generator constructor, add a constructor method like so:
```js
-module.exports = class extends Generator {
+import Generator from "yeoman-generator";
+
+export default class extends Generator {
// The name `constructor` is important here
constructor(args, opts) {
// Calling the super constructor is important so our generator is correctly set up
super(args, opts);
// Next, add your custom code
- this.option('babel'); // This method adds support for a `--babel` flag
+ this.option("babel"); // This method adds support for a `--babel` flag
}
-};
+}
```
### Adding your own functionality
@@ -135,20 +131,19 @@ Every method added to the prototype is run once the generator is called--and usu
Let's add some methods:
```js
-module.exports = class extends Generator {
+export default class extends Generator {
method1() {
- this.log('method 1 just ran');
+ this.log("method 1 just ran");
}
method2() {
- this.log('method 2 just ran');
+ this.log("method 2 just ran");
}
-};
+}
```
When we run the generator later, you'll see these lines logged to the console.
-
## Running the generator
At this point, you have a working generator. The next logical step would be to run it and see if it works.
@@ -163,7 +158,6 @@ npm link
That will install your project dependencies and symlink a global module to your local file. After npm is done, you'll be able to call `yo name` and you should see the `this.log`, defined earlier, rendered in the terminal. Congratulations, you just built your first generator!
-
### Finding the project root
While running a generator, Yeoman will try to figure some things out based on the context of the folder it's running from.
@@ -174,7 +168,6 @@ The Storage module creates the `.yo-rc.json` file. Calling `this.config.save()`
So, if your generator is not running in your current working directory, make sure you don't have a `.yo-rc.json` somewhere up the directory tree.
-
## Where to go from here?
After reading this, you should be able to create a local generator and run it.
diff --git a/app/authoring/integrating-yeoman.md b/app/authoring/integrating-yeoman.md
index 474d3697..4498831d 100644
--- a/app/authoring/integrating-yeoman.md
+++ b/app/authoring/integrating-yeoman.md
@@ -29,7 +29,7 @@ In this example, let's assume `npm` wants to provide a `npm init` command to sca
First step is to instantiate a new environment instance.
```js
-var yeoman = require('yeoman-environment');
+var yeoman = require("yeoman-environment");
var env = yeoman.createEnv();
```
@@ -38,12 +38,12 @@ Then, we'll want to register our `generator-npm` so it can be used later. You ha
```js
// Here we register a generator based on its path. Providing the namespace
// is optional.
-env.register(require.resolve('generator-npm'), 'npm:app');
+env.register(require.resolve("generator-npm"), "npm:app");
// Or you can provide a generator constructor. Doing so, you need to provide
// a namespace manually
var GeneratorNPM = generators.Base.extend(/* put your methods in here */);
-env.registerStub(GeneratorNPM, 'npm:app');
+env.registerStub(GeneratorNPM, "npm:app");
```
Note that you can register as many generators as you want. Registered generators are just made available throughout the environment (to allow composability for example).
@@ -52,10 +52,10 @@ At this point, your environment is ready to run `npm:app`.
```js
// In its simplest form
-env.run('npm:app', done);
+env.run("npm:app", done);
// Or passing arguments and options
-env.run('npm:app some-name', { 'skip-install': true }, done);
+env.run("npm:app some-name", { "skip-install": true }, done);
```
There you go. You just need to put this code in a `bin` runnable file and you can run a Yeoman generator without using `yo`.
@@ -66,7 +66,7 @@ But what if you wish to provide access to every Yeoman generator installed on a
```js
env.lookup(function () {
- env.run('angular');
+ env.run("angular");
});
```
@@ -110,12 +110,14 @@ An adapter should provide at least three methods.
### `Adapter#prompt()`
-It provides the question-answer functionality (for instance, when you start `yo`, a set of possible actions is prompted to the user). Its signature and behavior follows these of [Inquirer.js](https://github.com/SBoudrias/Inquirer.js). When a generators call `this.prompt`, the call is in the end handled by the adapter.
+It provides the question-answer functionality (for instance, when you start `yo`, a set of possible actions is prompted to the user). Its signature and behaviour follows these of [Inquirer.js](https://github.com/SBoudrias/Inquirer.js). When a generators call `this.prompt`, the call is in the end handled by the adapter.
### `Adapter#diff()`
+
Called internally when a conflict is encountered and the user ask for a diff between the old and the new file (both files content is passed as arguments).
### `Adapter#log()`
+
It's both a function and an object intended for generic output.
See [`lib/util/log.js`](https://github.com/yeoman/environment/blob/master/lib/util/log.js) for the complete list of methods to provide.
diff --git a/app/authoring/running-context.md b/app/authoring/running-context.md
index 8b021d3a..f0619c1d 100644
--- a/app/authoring/running-context.md
+++ b/app/authoring/running-context.md
@@ -20,47 +20,50 @@ Now that you know the prototype methods are considered to be a task, you may won
1. Prefix method name by an underscore (e.g. `_private_method`).
- ```js
- class extends Generator {
- method1() {
- console.log('hey 1');
- }
-
- _private_method() {
- console.log('private hey');
- }
- }
- ```
+ ```js
+ class extends Generator {
+ method1() {
+ console.log('hey 1');
+ }
+
+ _private_method() {
+ console.log('private hey');
+ }
+ }
+ ```
+
2. Use instance methods:
- ```js
- class extends Generator {
- constructor(args, opts) {
- // Calling the super constructor is important so our generator is correctly set up
- super(args, opts)
+ ```js
+ class extends Generator {
+ constructor(args, opts) {
+ // Calling the super constructor is important so our generator is correctly set up
+ super(args, opts)
- this.helperMethod = function () {
- console.log('won\'t be called automatically');
- };
- }
- }
- ```
+ this.helperMethod = function () {
+ console.log('won\'t be called automatically');
+ };
+ }
+ }
+ ```
3. Extend a parent generator:
- ```js
- class MyBase extends Generator {
- helper() {
- console.log('methods on the parent generator won\'t be called automatically');
- }
- }
-
- module.exports = class extends MyBase {
- exec() {
- this.helper();
- }
- };
- ```
+ ```js
+ class MyBase extends Generator {
+ helper() {
+ console.log(
+ "methods on the parent generator won't be called automatically"
+ );
+ }
+ }
+
+ export default class extends MyBase {
+ exec() {
+ this.helper();
+ }
+ }
+ ```
## The run loop
@@ -86,8 +89,8 @@ You can also group multiple methods to be run together in a queue by using a has
Generator.extend({
priorityName: {
method() {},
- method2() {}
- }
+ method2() {},
+ },
});
```
@@ -102,7 +105,7 @@ The available priorities are (in running order):
5. `writing` - Where you write the generator specific files (routes, controllers, etc)
6. `conflicts` - Where conflicts are handled (used internally)
7. `install` - Where installations are run (npm, bower)
-8. `end` - Called last, cleanup, say _good bye_, etc
+8. `end` - Called last, clean up, say _good bye_, etc
Follow these priorities guidelines and your generator will play nice with others.
diff --git a/app/authoring/testing.md b/app/authoring/testing.md
index aa9f53f5..80abdc4d 100644
--- a/app/authoring/testing.md
+++ b/app/authoring/testing.md
@@ -19,13 +19,13 @@ Usually the best way to organize your tests is to separate each generator and su
In code, you should end up with a structure similar to this:
```js
-describe('backbone:app', function () {
- it('generates a project with require.js', function () {
- // assert the file exist
- // assert the file uses AMD definition
+describe("backbone:app", function () {
+ it("generates a project with require.js", function () {
+ // assert the file exist
+ // assert the file uses AMD definition
});
- it('generates a project with webpack');
+ it("generates a project with webpack");
});
```
@@ -34,7 +34,7 @@ describe('backbone:app', function () {
Yeoman provide test helpers methods. They're contained inside the `yeoman-test` package.
```js
-var helpers = require('yeoman-test');
+var helpers = require("yeoman-test");
```
You can check [the full helpers API here](https://github.com/yeoman/yeoman-test).
@@ -42,48 +42,51 @@ You can check [the full helpers API here](https://github.com/yeoman/yeoman-test)
The most useful method when unit testing a generator is `helpers.run()`. This method will return a [RunContext](https://github.com/yeoman/yeoman-test/blob/master/lib/run-context.js) instance on which you can call method to setup a directory, mock prompt, mock arguments, etc.
```js
-var path = require('path');
+var path = require("path");
-it('generate a project', function () {
+it("generate a project", function () {
// The object returned acts like a promise, so return it to wait until the process is done
- return helpers.run(path.join(__dirname, '../app'))
- .withOptions({ foo: 'bar' }) // Mock options passed in
- .withArguments(['name-x']) // Mock the arguments
- .withPrompts({ coffee: false }) // Mock the prompt answers
- .withLocalConfig({ lang: 'en' }) // Mock the local config
- .then(function() {
+ return helpers
+ .run(path.join(__dirname, "../app"))
+ .withOptions({ foo: "bar" }) // Mock options passed in
+ .withArguments(["name-x"]) // Mock the arguments
+ .withPrompts({ coffee: false }) // Mock the prompt answers
+ .withLocalConfig({ lang: "en" }) // Mock the local config
+ .then(function () {
// assert something about the generator
});
-})
+});
```
Sometimes you may want to construct a test scenario for the generator to run with existing contents in the target directory. In which case, you could invoke `inTmpDir()` with a callback function, like so:
```js
-var path = require('path');
-var fs = require('fs-extra');
+var path = require("path");
+var fs = require("fs-extra");
-helpers.run(path.join(__dirname, '../app'))
+helpers
+ .run(path.join(__dirname, "../app"))
.inTmpDir(function (dir) {
// `dir` is the path to the new temporary directory
- fs.copySync(path.join(__dirname, '../templates/common'), dir)
+ fs.copySync(path.join(__dirname, "../templates/common"), dir);
})
.withPrompts({ coffee: false })
.then(function () {
- assert.file('common/file.txt');
+ assert.file("common/file.txt");
});
```
You can also perform asynchronous task in your callback:
```js
-var path = require('path');
-var fs = require('fs-extra');
+var path = require("path");
+var fs = require("fs-extra");
-helpers.run(path.join(__dirname, '../app'))
+helpers
+ .run(path.join(__dirname, "../app"))
.inTmpDir(function (dir) {
var done = this.async(); // `this` is the RunContext object.
- fs.copy(path.join(__dirname, '../templates/common'), dir, done);
+ fs.copy(path.join(__dirname, "../templates/common"), dir, done);
})
.withPrompts({ coffee: false });
```
@@ -91,10 +94,11 @@ helpers.run(path.join(__dirname, '../app'))
The run Promise will resolve with the directory that the generator was run in. This can be useful if you want to use a temporary directory that the generator was run in:
```js
-helpers.run(path.join(__dirname, '../app'))
+helpers
+ .run(path.join(__dirname, "../app"))
.inTmpDir(function (dir) {
var done = this.async(); // `this` is the RunContext object.
- fs.copy(path.join(__dirname, '../templates/common'), dir, done);
+ fs.copy(path.join(__dirname, "../templates/common"), dir, done);
})
.withPrompts({ coffee: false })
.then(function (dir) {
@@ -105,42 +109,40 @@ helpers.run(path.join(__dirname, '../app'))
If your generator calls `composeWith()`, you may want to mock those dependent generators. Using `#withGenerators()`, pass in array of arrays that use `#createDummyGenerator()` as the first item and a namespace for the mocked generator as a second item:
```js
-var deps = [
- [helpers.createDummyGenerator(), 'karma:app']
-];
-return helpers.run(path.join(__dirname, '../app')).withGenerators(deps);
+var deps = [[helpers.createDummyGenerator(), "karma:app"]];
+return helpers.run(path.join(__dirname, "../app")).withGenerators(deps);
```
If you hate promises, you can use the `'ready'`, `'error'`, and `'end'` Events emitted:
```js
-helpers.run(path.join(__dirname, '../app'))
- .on('error', function (error) {
- console.log('Oh Noes!', error);
+helpers
+ .run(path.join(__dirname, "../app"))
+ .on("error", function (error) {
+ console.log("Oh Noes!", error);
})
- .on('ready', function (generator) {
+ .on("ready", function (generator) {
// This is called right before `generator.run()` is called
})
- .on('end', done);
+ .on("end", done);
```
-You can also run a generator importing it as a module. This is usefull if the source code of your generator is transpiled.
+You can also run a generator importing it as a module. This is useful if the source code of your generator is transpiled.
You will need to provide the following settings to `run`:
+
- `resolved`: Path to the generator, e.g. `../src/app/index.js`
- `namespace`: Namespace of the generator, e.g. `mygenerator:app`
```js
-var MyGenerator = require('../src/app');
+var MyGenerator = require("../src/app");
-helpers.run(MyGenerator, {
- resolved: require.resolve(__dirname, '../src/app/index.js'),
- namespace: 'mygenerator:app'
+helpers.run(MyGenerator, {
+ resolved: require.resolve(__dirname, "../src/app/index.js"),
+ namespace: "mygenerator:app",
});
-
```
-
## Assertions helpers
Yeoman extends the [native assert module](https://nodejs.org/api/assert.html) with generator related assertions helpers. You can see the full list of assertions helpers on the [`yeoman-assert` repository](https://github.com/yeoman/yeoman-assert).
@@ -148,13 +150,13 @@ Yeoman extends the [native assert module](https://nodejs.org/api/assert.html) wi
Require the assertion helpers:
```js
-var assert = require('yeoman-assert');
+var assert = require("yeoman-assert");
```
### Assert files exists
```js
-assert.file(['Gruntfile.js', 'app/router.js', 'app/views/main.js']);
+assert.file(["Gruntfile.js", "app/router.js", "app/views/main.js"]);
```
`assert.noFile()` assert the contrary.
@@ -162,7 +164,10 @@ assert.file(['Gruntfile.js', 'app/router.js', 'app/views/main.js']);
### Assert a file content
```js
-assert.fileContent('controllers/user.js', /App\.UserController = Ember\.ObjectController\.extend/);
+assert.fileContent(
+ "controllers/user.js",
+ /App\.UserController = Ember\.ObjectController\.extend/
+);
```
`assert.noFileContent()` assert the contrary.
diff --git a/app/authoring/user-interactions.md b/app/authoring/user-interactions.md
index 5104c35f..16cd2cb2 100644
--- a/app/authoring/user-interactions.md
+++ b/app/authoring/user-interactions.md
@@ -21,26 +21,26 @@ Prompts are the main way a generator interacts with a user. The prompt module is
The `prompt` method is asynchronous and returns a promise. You'll need to return the promise from your task in order to wait for its completion before running the next one. ([learn more about asynchronous task](/authoring/running-context.html))
```js
-module.exports = class extends Generator {
+export default class extends Generator {
async prompting() {
const answers = await this.prompt([
{
type: "input",
name: "name",
message: "Your project name",
- default: this.appname // Default to current folder name
+ default: this.appname, // Default to current folder name
},
{
type: "confirm",
name: "cool",
- message: "Would you like to enable the Cool feature?"
- }
+ message: "Would you like to enable the Cool feature?",
+ },
]);
this.log("app name", answers.name);
this.log("cool feature", answers.cool);
}
-};
+}
```
Note here that we use the [`prompting` queue](/authoring/running-context.html) to ask for feedback from the user.
@@ -50,21 +50,21 @@ Note here that we use the [`prompting` queue](/authoring/running-context.html) t
A very common scenario is to use the user answers at a later stage, e.g. in [`writing` queue](/authoring/file-system.html). This can be easily achieved by adding them to `this` context:
```js
-module.exports = class extends Generator {
+export default class extends Generator {
async prompting() {
this.answers = await this.prompt([
{
type: "confirm",
name: "cool",
- message: "Would you like to enable the Cool feature?"
- }
+ message: "Would you like to enable the Cool feature?",
+ },
]);
}
writing() {
this.log("cool feature", this.answers.cool); // user answer `cool` used
}
-};
+}
```
#### Remembering user preferences
@@ -78,7 +78,7 @@ this.prompt({
type: "input",
name: "username",
message: "What's your GitHub username",
- store: true
+ store: true,
});
```
@@ -112,7 +112,7 @@ This method must be called inside the `constructor` method. Otherwise Yeoman won
Here is an example:
```js
-module.exports = class extends Generator {
+export default class extends Generator {
// note: arguments and options should be defined in the constructor.
constructor(args, opts) {
super(args, opts);
@@ -123,7 +123,7 @@ module.exports = class extends Generator {
// And you can then access it later; e.g.
this.log(this.options.appname);
}
-};
+}
```
Argument of type `Array` will contain all remaining arguments passed to the generator.
@@ -151,7 +151,7 @@ The options hash (the second argument) accepts multiple key-value pairs:
Here is an example:
```js
-module.exports = class extends Generator {
+export default class extends Generator {
// note: arguments and options should be defined in the constructor.
constructor(args, opts) {
super(args, opts);
@@ -162,7 +162,7 @@ module.exports = class extends Generator {
// And you can then access it later; e.g.
this.scriptSuffix = this.options.coffee ? ".coffee" : ".js";
}
-};
+}
```
## Outputting Information
@@ -172,11 +172,11 @@ Outputting information is handled by the `this.log` module.
The main method you'll use is simply `this.log` (e.g. `this.log('Hey! Welcome to my awesome generator')`). It takes a string and outputs it to the user; basically it mimics `console.log()` when used inside of a terminal session. You can use it like so:
```js
-module.exports = class extends Generator {
+export default class extends Generator {
myAction() {
this.log("Something has gone wrong!");
}
-};
+}
```
There's also some other helper methods you can find in the [API documentation](https://yeoman.github.io/environment/TerminalAdapter.html).