Platform : windows

I was checking out yeoman-app and found that when running a generator all the generator files are created in the folder where I run the app irrespective of whet folder I choose I raised an issue here yeoman/yeoman-app#104

But then I wrote a simple test and tried it out as below and the issue seems to be in yeoman-environment itself, say I executed this in a folder d:/app folder and i have a sub folder there testDir and I switched to the sub directory before invoking env.run() but still files were created in the d:/app folder instead of d:/app/testDir folder. But there is a empty set of all the folders alone created inside d:/app/testDir

Seems like the mkdir commands are executed on the current directory while copy files are executed on the directory where environment was initilized

var fs = require('fs');
var _ = require('lodash');
var yeoman = require('yeoman-environment');
var env = yeoman.createEnv();

var init = function () {
  //process.chdir('./testDir');
  console.log('init yeoman-environment');
  console.log(process.cwd());
  // Here we register a jhipster generator based on its path. Providing the namespace
  env.register(require.resolve('generator-jhipster'), 'jhipster:app');
};

var runApp = function () {
  console.log('running yo app');
  run('jhipster:app', './testDir')
};

function sendCommandToAppWindow(name, data) {
  if (data instanceof Error) {
    console.error(data);
    data = data.toString();
  }
}

function run(generatorName, cwd) {

  if (!generatorName) {
    return sendCommandToAppWindow('generator:error', new Error('You must provide a generator name'));
  }

  if (!fs.existsSync(cwd)) {
    return sendCommandToAppWindow('generator:error', new Error('The given path does not exist or is not a directory'));
  }
  console.log(process.cwd());
  process.chdir(cwd);
  console.log(process.cwd());

  function done(err) {
    if (err) {
      return sendCommandToAppWindow('generator:error', err);
    }
  }

  // invoke generator
  env.run(generatorName, { 'skip-install': true }, done);
}

module.exports = {
  init : init,
  runApp : runApp
}

Hi,

I've been working with yeoman-environment over the past couple of days as I'm wanting it scaffold out various bits from a Nodejs back end. Yeoman's been great so far.

However I'm having an issue when it's trying to resolve a namespace from a path.

The following path will resolve the namespace incorrectly (in environment.js:Environment.prototype.namespace)

c:\projects\yeoman\generators\generator-example\generators\app\index.js 
EXPECTED: example:app
ACTUAL: example:generators:app

Lookups:

['.', 'generators', 'lib/generators']

This happens because the first "generators" in the path is being replaced. I believe this should replace the last matched lookup in the reduce function like:

  // if `ns` contain a lookup dir in it's path, remove it.
  ns = lookups.reduce(function (ns, lookup) {
    // ensure that the lookup is removed from the lowest level folder, and that partial folder names aren't removed
    var folders = ns.split(path.sep);
    var replaceIndex = folders.lastIndexOf(lookup);
    if (replaceIndex > -1) {
        folders.splice(replaceIndex, 1);
    }
    var resolvedPath = folders.join(path.sep);
    return resolvedPath;
  }, ns);

This will also avoid it doing replaces like:
...\generator-example\generators-foo\app\index.js
...\generator-example-foo\app\index.js

Hi, I'm not sure if this is possible, so if not, just tell me and close the issue :).

So in a sub-generator, it's possible to define arguments and options as described in the section Arguments (and Options). Is it possible to retrieve those together with the generators metadata?

The reason I'm asking this is because I'm writing a VS Code plugin and I support sub-generators. But some sub-generators have arguments, which I'm not aware off. As you can see in this block off code, I'm running the sub-generator, if it throws an error with a specific message, I show an input box where the user can pass in it's argument. This feels very hacky and I was hoping for a better way.

The same goes for the options. If I could retrieve the options of a sub-generator, I can show a multi-select list where the user can pick the options he wants.

Any thoughts on this?

Right now we can only pass boolean params:

  env.run('angular', {'skip-install': true}, err => {
    console.log('done');
  });

(from the docs)

I'd like to pass Strings/Numbers, so that I can use it with yeoman-option-or-prompt

/tmp/ curl $(npm view [email protected] dist.tarball) | tar -zt
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1459  100  1459    0     0  10192      0 --:--:-- --:--:-- --:--:-- 10202
package/package.json
package/readme.md

Is this intentional? Its breaking react-native, as seen at facebook/react-native#8610

The build is currently failing in 0.10 and 0.12. It would be great to get these green again to have confidence that #61 is truly resolved.

1) Environment Resolver #lookup() "before all" hook:
     Error: timeout of 100000ms exceeded. Ensure the done() callback is being called in this test.

Just some thoughts and questions on things we can do to simplify the API. I'd be happy to open separate ticket for things, but want to hear them out first.

• Why does this module depend on yeoman-generator? And shouldn't the usage example be var yeoman = require('yeoman-generator'); => var env = require('yeoman-environment');?
• I think we should drop env.createEnv() as you can already do new Env()? Which is IMHO better.

// The #lookup() method will search the user computer for installed generators. The search
// if done from the current working directory.
env.lookup(function () {
  env.run('angular', { 'skip-install': true }, done);
});

Any reason we have to do the lookup first? Can't just env.run lazy trigger the lookup on the first run?

I would like to have a way to run a generator with a single method call.

The end event doesn't seem to work: https://github.com/yeoman/yo/blob/8f8d16e10c13d11faf7034ca2f1e59589a6081bd/cli.js#L78-L80 How is it different from the callback to env.run? Can we drop it?

Is the help method used at all

env.getGeneratorsMeta() is weird as it only works after env.lookup. Could we instead pass generator metadata in the env.lookup callback?

I'm not a big fan of the aliasing functionality. It complicates things a lot. Is there a way we can drop or simplify this?

https://github.com/yeoman/yo/blob/8f8d16e10c13d11faf7034ca2f1e59589a6081bd/cli.js#L75-L76

Anything anyone else think can be improved?

I can run the following command successfully and get the proper name of Example Service in this.options.name:
yo my-generator:generate service "Example Service"

However, when I run the following command, the name is truncated as "Example in this.options.name:
env.run('yo my-generator:generate service "Example Service"', {'skip-install': true}, function (err) {});

My package.json contains:
"yeoman-environment": "^1.6.6"
"yeoman-generator": "^1.0.1"

Currently there is no way to get all possible options for an yeoman generator (I mean '--coffee' and etc). I think this functionality can be very useful

This page currently says:

var yeoman = require('yeoman-generator');

var env = yeoman.createEnv();

// The #lookup() method will search the user computer for installed generators. The search
// if done from the current working directory.
env.lookup(function () {
  env.run('angular', { 'skip-install': true }, done);
});

where that first line should be:

var yeoman = require('yeoman-environment');

The resolver.getNpmPaths() method makes some basically wrong assumptions.

The entire block from line 123 to line 142 (comments included) it's too based on the experience/environment of the developer who implemented the code.

Npm allows to configure a custom path for global node_modules directory and the default one can also be different from one platform to another.

This can lead to unexpected behaviour: I configured a custom npm prefix, installed the generator-webapp globally without problems and now I can't find it in the list of available generators.

It would be better to take advantage of npm api to programmatically get the global node_modules path, in order to ensure a more "environment-agnostic" way to search for generators.

Check out these resources:

• Npm readme - Using npm Programmatically
• SO question

The programmatic api seems to be supported from npm version 2.0.1 (the oldest one on Github).

This is a simple snippet that shows how to get it with npm api:

var npm = require('npm');

function npmGlobalDir(cb) {
  npm.load({}, function(err) {
    if (err) {
      throw err;
    }

    cb(npm.globalDir);
  });
}

Obviously, the getNpmPaths() should no longer be a synchronous method that returns a value, but one which expects a callback.
Also the lookup() method should change accordingly.

I reported touching/revisiting that part of our code a very long time (way too long)

File is here: https://github.com/yeoman/environment/blob/master/test/environment.js#L458

Events tested against generators should definitively be removed from this repo and ported to the generator system own files.

The one related to the environment should be cleaned up to make it relevant.

In a project that I'm working on, I'm implementing plugin support using the approach that Yeoman uses:

• Scan all npm paths for a matching pattern (like generator- but related to my project).
• Require them accordingly.

I found yeoman-environment's getNpmPaths() while attempting to write a similar function. In order to reuse this code, I'm requiring the whole yeoman-environment, but I feel this function could be a candidate for a separate module, as other people might be trying to resolve this issue as well, and they could rely on the experimentation you put in when implementing that function.

What do you think about extracting this function as a separate node module (maybe something like npm-path-find)?

Hello,
Dear Yeoman maintainers,

A while ago I submitted a PR (landed in 72c91a8) which implemented a new method. A while ago I woke up and noticed that there was a release: 1.2.7. That's a patch version bump. Really cool, thanks for the quick release, though, why a patch version bump?

So I have a question: does the yeoman team follow semver? If not, is there a possibility to do so, please? If you don't want to use semver (which is the default convention on npm), I think you will have to warn for that in the documentation.

I see many people using the ^ when it comes to deps developed by the yeoman team. That would then be invalid as npm assumes semver by default.

Thanks in advance.
东 栋

The Environment constructor should be strict and allow only valid arguments (and throw otherwise).

The checks for partial signature or invalid inputs should be done in the factory function (Environment.createEnv()).

To be good semver citizens I guess our first release will be 1.0 (plus the system have been pretty stable as it's only extracted from yeoman-generator).

So, it's a good occasion to drop the bad parts. I open this thread as a free discussion. I'd prefer we keep changes small and focused, but bigger ideas are welcomed too.

Todos for 1.0

• Remove property aliases (args <> arguments, etc) - These are just confusing. Let's stick with one version.
• Remove multiple kind of data expected. We often allow Strings with spaces or Array as parameter - let's just accept array.
• Generate Environment API doc
• Port yeoman-generator to use this module (of course)
• Port yo to use this module

I am trying to embed my generator in my project using the getByPath method that was introduced here in PR #11

My folder structure looks like this:

- /generators
--- /adrizer     <---- My embeded generator
------- /generators
---------- /app
------------- index.js
---------- /test
------------- index.js
------- package.json

I am trying to test running this generator using this command:

./node_modules/.bin/yo ./generators/adrizer adrizer

And I get this error:

module.js:471
    throw err;
    ^

Error: Cannot find module '/Users/adamduro/Workspace/projects/adrizer-dashboard/generators/adrizer/'
    at Function.Module._resolveFilename (module.js:469:15)
    at Function.resolve (internal/module.js:27:19)
    at Environment.resolveModulePath (/Users/adamduro/Workspace/projects/adrizer-dashboard/node_modules/yeoman-environment/lib/environment.js:461:18)
    at Environment.register (/Users/adamduro/Workspace/projects/adrizer-dashboard/node_modules/yeoman-environment/lib/environment.js:161:25)
    at Environment.getByPath (/Users/adamduro/Workspace/projects/adrizer-dashboard/node_modules/yeoman-environment/lib/environment.js:276:10)
    at Environment.get (/Users/adamduro/Workspace/projects/adrizer-dashboard/node_modules/yeoman-environment/lib/environment.js:265:10)
    at Environment.create (/Users/adamduro/Workspace/projects/adrizer-dashboard/node_modules/yeoman-environment/lib/environment.js:296:24)
    at Environment.run (/Users/adamduro/Workspace/projects/adrizer-dashboard/node_modules/yeoman-environment/lib/environment.js:372:24)
    at /Users/adamduro/Workspace/projects/adrizer-dashboard/node_modules/yo/lib/cli.js:140:11
    at Array.forEach (native)

Any idea what I am doing wrong? Or was there a change to the way that require.resolve work in Node 6?

We currently have Environment.getGeneratorsMeta(), but it returns more than we usually need and we need to manually format the output. Would be nice to have a simple method to just get the generator names as an array.

Currently I have this hack in place that I would like to remove: https://github.com/yeoman/yo/blob/681bf11ee5619fd76a093abb04a660784a835d96/lib/utils/index.js#L8-L10

I was trying to use yeoman-environment in project that was built with webpack and encountered a problem with generators registration.
Webpack replace original require function with it's own, so trying to require a generator absolute path caused an error 'Cannot find module'.
My proposal is to allow to user to pass it's own require function to createEnv method with options parameter and use this function in resolveModulePath.

If you think my proposal is good I would happy to make PR (Changes that I propose are follows: https://github.com/anta-semenov/environment/commit/4505b7813913961cc2e151f7da82b98550d67440 )

re #5 (comment)

With the paths.reverse() call at https://github.com/yeoman/environment/blob/master/lib/resolver.js#L144 it causes the global paths to be returned first. Is that intended? It seems like we should go from the most specific -- the current project -- to the least specific -- the globally installed modules.

Currently Environment provides the function findGeneratorsIn, which searches a list of paths and returns a list of generators within those paths. From what I can tell, the user still has to loop through each found module, registering any generators found within. If I am mistaken by all means correct me.

I would like to propose the addition of a registerGeneratorsIn method which receives a list of paths, uses the findGeneratorsIn function to find all the modules within these paths, and then registers all of the generators/sub-generators in the found modules. Namespaces could be generated using the namespace method.

If this addition makes sense I would be happy to start working on a PR.

Super simple method, but IMHO should be here and not in yo.

https://github.com/yeoman/yo/blob/681bf11ee5619fd76a093abb04a660784a835d96/lib/utils/index.js#L4-L6

When reading some code or doc, I came across stuff like yo name:sub:more (cf here), but reading some other code source, it looks like it will never be able to handle such a sub-sub-generator (see here) but I'm not 100% sure...

So... is there a way to handle sub-sub-generators? Is there a meaning to do something like yo angular:common:all? If not, would it be a good idea to consider supporting deeper level of sub-generators?

jshint throws hard on our tests about undefined globals. They are in the .jshintrc so really I have no idea what is going on there...

probably related to #67, I'm trying to do a fresh install of yo and when running it get the following error:

Error: Cannot find module 'yeoman-environment'
    at Function.Module._resolveFilename (module.js:325:15)
    at Function.Module._load (module.js:276:25)
    at Module.require (module.js:353:17)
    at require (internal/module.js:12:17)
    at Object.<anonymous> (/usr/local/Cellar/nvm/0.25.4/versions/node/v4.4.7/lib/node_modules/yo/lib/router.js:9:23)
    at Module._compile (module.js:409:26)
    at Object.Module._extensions..js (module.js:416:10)
    at Module.load (module.js:343:32)
    at Function.Module._load (module.js:300:12)
    at Module.require (module.js:353:17)

I looked in the node_modules folder and yeoman-environment is missing on the new install. manually installing 1.6.1 resolves the above error.

Node.js version: 4.4.7
npm version: 3.10.3

looks like make was used because gulp-mocha was broken. Should probably just run mocha directly no?

The way we run a generator currently, is that we'll check at the generator namespace provided, and get rid of any namespace one by one until we find a match:

$ yo my:cool:generator
try > my:cool:generator
try > my:cool
try > my

This mean if someone typoed the subgenerator name, we'll always end up running the app generator.

This is a buggy behavior and we should fix it.

The #lookup() test install generators for real and is taking quite a while to run. We could probably speed this test a lot by stopping using npm and mocking the full environment to run the test in.

The whole point of extracting this is so runners like yo can depend on the environment without having to require all the junk in yeoman-generator.

Hi! Yeoman environment has a great API for integration with an external tool. I miss just one functionality : I need an ability to get (to show) a previous step. Something like 'goBack' if user want to change previous answer.

We should support running a generators that are part of a project.

I see two solutions:

1. Allow paths as generator name (e.g.: yo ./generators/generator-local)
2. Add a standard local directory to the generators lookup (like always lookup for $PWD/yeoman - or similar)

Adding a lookup should be easy enough. Running via paths could be more difficult as that would probably require to change the way alias/namespace is working.

From what I understand about composeWith, the method follows the priority group execution in the runLoop. For instance, if you call composeWith under install the composed generator and main generator should call install and any priority group lower (e.g. end).

This behavior seems to be ignored if the force option is passed in like the following:

 this.composeWith(require.resolve('../turbo'),{ force: true});

In addition, if you call the generator in the CLI and pass the force option like so

yo generator-something  --force true

The prompt still asks if you want to overwrite which shouldn't given the option.

I have two questions. Is there a way where we can attach an EventEmitter to the IO procedures so that if a copying fails or does not happen (a priority group is not run) the user knows about it?

I really like ES6 and build a generator using ES6 syntax in source.
I use Babel to transpile source to ES5.
Since Babel upgrade to 6.0 and Kill CommonJS default export behaviour

export default MyGenerator;

will be transformed to:

exports.default = MyGenerator;

and module.exports = exports["default"] will no longer exist

yeoman-environment can't discover my generator for me.

Consider add support to require('generator-xxx').default for all generators compiled with Babel?

I just re-installed one of my packages that depends on yeoman-test and have started getting an error because this package relies on @sindresorhus's https://github.com/sindresorhus/untildify version 3.0.1 which now requires node 4 and uses const. The semver tree has broken causing my once stable build to now fail.

I am currently using node 0.12.13 and my package has a dev dep on "yeoman-test": "1.0.0"

mygenerator/node_modules/yeoman-test/node_modules/yeoman-environment/node_modules/untildify/index.js:2
const osHomedir = require('os-homedir');
^^^^^
SyntaxError: Use of const in strict mode.

Each time we publish a new tag, we should launch a Travis-CI process to release a new version of the API documentation.

A shareable solutions for a couple of our repositories would be very awesome. See:

• yeoman/generator#673

For some reason global generator cannot be found on io.js - this also cause a test failure on Travis when using io.js.

Note: I have not reproduce this myself of a system, I need to investigate and reproduce. We know we have a test failure. That doesn't mean it is not working.

Initially opened here: yeoman/yo#231
npm documentation: npm/npm#5239

This will create module under a different kind of path, e.g.: /usr/local/lib/node_modules/@foo/generator-bar/

That's just weird, and much better to use writeln if you want a linebreak, which should append a \n.

Hello there,

I'm not sure if this is supposed to work like this or if this is an error. But, when you call the same environment to run a generator again, it causes an assertion error for copy and copyTpl with glob patterns:

AssertionError: Trying to copy from a source that does not exist: envir-test/node_modules/generator-generator/subgenerator/templates/templates/**

Example :

const yeoman = require('yeoman-environment');
const env = yeoman.createEnv();

env.lookup(() => {
  env.run('generator', {'skip-install': true}, err => {
    console.log('done');
    env.run('generator', {'skip-install': true}, err => {
        console.log('done');
    });
  });
});

Everything works fine if I create a new environment each time I execute the generator.

Versions:

• yeoman-environment: "^1.6.6"
• generator-generator: "^3.1.0",
• Node v7.10.0
• Windows 10

Might be related to #52

I'm running into an issue when trying to load installed generators with env#getGeneratorsMeta(), and I think it's related to nvm and npm prefix being different than the defaults.

My test sample is something like:

var env = require('yeoman-environment').createEnv();
env.lookup((err) => {
  console.log(env.getGeneratorsMeta());
});

Looking at the getNpmPaths() method, I can see that $NODE_PATH is used when defined, and I can get the env lookup working with:

NODE_PATH="/home/user/.nvm/versions/nodes/v6.0.0/lib/node_modules" node test.js

My question is, would you agree on adding the result of npm prefix to the lookup paths automatically ?

env.lookup() is asynchronous, so we might be able to introduce a call to .exec('npm prefix -g') if you don't mind the performance penalty it might introduce.

Alternatively, if you don't want it to be the default behavior, would it be possible to define custom paths? something like:

// env.lookup([paths, ], cb);

env.lookup(['/home/user/.nvm/versions/node/v6.0.0/lib/node_modules'], function() {});

Either way, it would fix the lookup for nvm installed yeoman and generators. This doesn't apply when yeoman-environment is installed globally, yo works fine in this case.

I want to use es2015 module style to create generator. I tried this style, code failed. I think the reason might be babel transform the follow code to module.exports.default = function AppGenerator() {}.

export default class AppGenerator extends Base {
}

This help method is command line specific and should be removed from this module.

To do so, we'll need to reimplement this method inside yo

main field should contain the path to the main generator .js file.

Linked from yeoman/generator#310

This have backward compatibility concerns and issue about how we then discover every sub-generators.

I'm currently using npm enterprise and I've published a generator to it. When I install it globally via:

npm install -g @mycompany/mygenerator

yeoman doesn't find the package because it is under the folder

@mycompany

I'll work on a PR that also calls findGeneratorsIn for each @namespace folder that is found.

In my project, I need to call the yeoman command in a Java class. It worked fine before(version 1.2.0) but after I upgrade it to 1.3.3, I get an error when running the 'yo.cmd' command. The yeoman command works fine when running it in a command windows directly.

Env:
Windows 7 64bit
Java 1.7.0_51 64bit
node v0.10.36
yo 1.3.3

When running the test code: java RunYo, the error message is:

fs.js:439
  return binding.open(pathModule._makeLong(path), stringToFlags(flags), mode);
                 ^
Error: ENOENT, no such file or directory 'C:\dev\tty'
    at Object.fs.openSync (fs.js:439:18)
    at Object.<anonymous> (C:\Users\myuser\AppData\Roaming\npm\node_modules\yo\node_modules\yeoman-environment\node_modules\inquirer\node_modules\ttys\index.js:9:18)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)
    at Object.<anonymous> (C:\Users\myuser\AppData\Roaming\npm\node_modules\yo\node_modules\yeoman-environment\node_modules\inquirer\lib\ui\baseUI.js:8:12)
    at Module._compile (module.js:456:26)

Below is the java test code:

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.io.PrintStream;

public class RunYo {

    public static void main(String[] args) {
        String cmd = "yo.cmd";

        try {
            Process process = Runtime.getRuntime().exec(cmd, null, null);
            readProcessOutput(process);
        } catch( IOException e ) {
            e.printStackTrace();
        }
    }

    private static void readProcessOutput(final Process process) {
        read(process.getInputStream(), System.out);
        read(process.getErrorStream(), System.err);
    }

    private static void read(InputStream inputStream, PrintStream out) {
        try {
            BufferedReader reader = new BufferedReader(new InputStreamReader(inputStream));

            String line;
            while( (line = reader.readLine()) != null ) {
                out.println(line);
            }

        } catch( IOException e ) {
            e.printStackTrace();
        } finally {

            try {
                inputStream.close();
            } catch( IOException e ) {
                e.printStackTrace();
            }
        }
    }

}

There is a similar issue in stack overflow reported recently:
http://stackoverflow.com/questions/28077848/windows-7-yeoman-generator-gulp-angular-not-finding-creating-directory-erro

this.log.table() wraps table() provided by the text-table package. The second argument for text-table's table() would allow for passing alignment and separator options (docs).

Would you consider updating the method signature to allow passing formatting options along, e.g. like:

log.table = function (opts, fmt) {
  var tableData = [];

  opts = Array.isArray(opts) ? { rows: opts } : opts;
  opts.rows = opts.rows || [];

  fmt = fmt || {};

  opts.rows.forEach(function (row) {
    tableData.push(row);
  });

  return table(tableData, fmt);
};

On a related note, the docstring mentions that table is a wrapper around cli-table instead of text-table. Might have historical reasons?

https://github.com/yeoman/environment/search?utf8=%E2%9C%93&q=cb

Here https://github.com/yeoman/environment/blob/master/lib/resolver.js#L140 you add default the linux path but default OS X path is '/usr/local/lib/node_modules/'.
So if I try to run non-globally installed yo it cannot find generators.