"There are no entries to pick from"

[nmaxcom]

First extension I installed in vscode. The instructions are very vague though, it doesn't mention if I have to install generators first or... I do have a Bootstrap generator I never use, but it's there, and when I run yo in vscode I get this:

[SamVerschueren]

It's just a runner, not an installer. https://github.com/SamVerschueren/vscode-yo/issues/15

Do you see your generator when running yo? Try installing another one and try again.

Let me know if it worked :).

[SamVerschueren]

Can you provide me with more information?

• Screenshot of the output when running yo on the commandline
• VS Code version
• Operating system
• Yo plugin version

[danwalmsley]

I'm having the same problem

[SamVerschueren]

This might be related to https://github.com/sindresorhus/fix-path/issues/6

[SamVerschueren]

I released version v0.7.2 which fixes the issue referred to in my previous post. Could you guys upgrade and test if this bug still occurs?

If not, is someone willing to debug this for me on his system? The value I'm interested in is the paths variable in environment.ts#L18. Thanks!

[SamVerschueren]

@jerkovicl Windows always returns win32

Is it possible to execute this tiny script?

'use strict';
const path = require('path');
const win32 = process.platform === 'win32';

const getNpmPaths = function () {
    if (process.env.NODE_PATH) {
        return process.env.NODE_PATH.split(path.delimiter);
    }

    require('fix-path')();

    // Get the npm path from the user env variables.
    const paths = process.env.PATH.split(path.delimiter).map(item => path.join(item, '..', 'lib', 'node_modules'));

    console.log(process.platform);

    // Default paths for each system
    if (win32) {
        paths.push(path.join(process.env.APPDATA, 'npm/node_modules'));
    } else {
        paths.push('/usr/lib/node_modules');
    }

    return paths.reverse();
};

console.log(getNpmPaths());

Don't forget to install fix-path

$ npm install fix-path

The output of that script should be helpfull in solving this bug.

---

Can you have a look in C:\Users\luka\AppData\Roaming\npm\node_modules. Is the generator installed in that directory?

[SamVerschueren]

Have you installed your generators globally with the -g (or --global) flag?

If not, can you try that?

If yes, is it possible to find out in what directory the generators are being installed?

[SamVerschueren]

They are being installed in this directory C:\Users\luka.npmrepo\node_modules

That doesn't seem like the default path. Have you changed the npm configuration in .npmrc or something?

Can you provide the following info?

• Output of npm config get prefix
• Can you find that path somewhere in npm config edit?

[SamVerschueren]

Alright, so this is the reason why some people don't see the generators. Might be Win 10 related. Thanks for the information!

PS. If you want to solve this quickly, you can add C:\Users\luka\.npmrepo\bin to your PATH variable. Don't forget to add bin at the end (even though it doesn't exist). If you do this, let me know if it works, might be usefull information :).

Edit: The solution won't work. Am trying to fix this ASAP.

[SamVerschueren]

@jerkovicl Can you upgrade to yo@0.7.3? Hopefully this is fixed now :).

[SamVerschueren]

Awesome! Thanks for all the information. Couldn't have done it without your help :+1: !

Still wondering why the path is that weird though :). Think it's Win 10 related.

[nmaxcom]

In my case (OP), i'm in Yosemite 10.10.5, vscode 0.7, and outside vscode I do see my generator in iTerm.

[SamVerschueren]

Alright, so it's not win 10 related. Can you execute the piece of code from above and show me the result? Have you upgraded to yo@7.0.3?

[SamVerschueren]

@david-driscoll Do you have any insights regarding this issue? Maybe some experience in atom-yeoman?

Edit: found the same bug in https://github.com/david-driscoll/atom-yeoman/issues/7

[SamVerschueren]

@nmaxcom It would help me a lot of you could provide me with

1. The location your generators are installed in
2. Output when running npm config get prefix (might be the same as 1.)
3. Output of the script provided in this comment

[nmaxcom]

1)

~ ls /usr/local/lib/node_modules
bower                 divshot-cli           grunt-cli             js-beautify           npm                   svgo                  uglifycss             yo
clean-css             generator-bootstrap   gulp                  jshint                nw                    tick                  uncss
csslint               generator-node-webkit html-minifier         n                     sass                  uglify-js             v8-profiler

2)

~ npm config get prefix
/usr/local

3)

~ node tmp.js
darwin
[ '/usr/lib/node_modules',
  '/lib/node_modules',
  '/usr/lib/node_modules',
  '/lib/node_modules',
  '/usr/lib/node_modules',
  'node_modules\npackage.json\ntmp.js\n/usr/local/lib/node_modules' ]

Hope it helps.

[SamVerschueren]

Thanks for the information! Helps me a lot.

[SamVerschueren]

@nmaxcom Sorry for the late reply, have been busy lately.

Can you run the command echo $PATH in the terminal and provide me with the output? It seems like the path is in the list but it isn't parsed correctly.

node_modules\npackage.json\ntmp.js\n/usr/local/lib/node_modules

I am wondering where that last entry comes from.

[nmaxcom]

Sure: /usr/local/bin /usr/bin /bin /usr/sbin /sbin

[SamVerschueren]

@nmaxcom Can you first have a look if if NODE_PATH is set with echo $NODE_PATH?

It might be an issue in fix-path. Can you execute this piece of code? It's the same as above but withouth the fix-path stuff.

'use strict';
const path = require('path');
const win32 = process.platform === 'win32';

const getNpmPaths = function () {
    if (process.env.NODE_PATH) {
        return process.env.NODE_PATH.split(path.delimiter);
    }

    // Get the npm path from the user env variables.
    const paths = process.env.PATH.split(path.delimiter).map(item => path.join(item, '..', 'lib', 'node_modules'));

    console.log(process.platform);

    // Default paths for each system
    if (win32) {
        paths.push(path.join(process.env.APPDATA, 'npm/node_modules'));
    } else {
        paths.push('/usr/lib/node_modules');
    }

    return paths.reverse();
};

console.log(getNpmPaths());

[chrisuehlinger]

Having this problem too, but it gets weirder. To start:

OS: Windows 7 vscode-yo: 0.7.3

PATH=C:\Users\cuehlinger\AppData\Local\Pandoc\;C:\Program Files (x86)\Microsoft VS Code\bin;C:\phantomjs\bin;C:\Program Files\nodejs;C:\ProgramData\chromedriver;C:\ProgramData\IEDriver;C:\ProgramData\apache-ant-1.9.6\bin;C:\ProgramData\apache-maven-3.3.3\bin;C:\ProgramData\curl;C:\Program Files (x86)\Android\android-sdk\platform-tools;C:\Users\cuehlinger\AppData\Roaming\npm

NODE_PATH was not originally set, I set it to C:\Users\cuehlinger\AppData\Roaming\npm\node_modules npm config -g get prefix returns C:\Program Files\nodejs

Now here's where it gets weird: npm used to install global stuff in C:\Users\cuehlinger\AppData\Roaming\npm\node_modules, but at some point switched and started using C:\Program Files\nodejs\node_modules for global installs instead. Both directories are in PATH, so global packages installed in either one can be used.

My guess is that the change came about in October when we were updating to node v4.x and npm v3.x. Either way, can you have vscode-yo just look in whichever directory npm is using?

Edit: My current versions: node v4.2.1, npm v3.3.11, VS Code v0.10.5

[SamVerschueren]

can you have vscode-yo just look in whichever directory npm is using?

That's what I'm trying to do here. But I can't seem to figure out what's wrong with the method. It should look at all the places in the your path, and althought the method works in most cases, for some people, it doesn't.

What would really help me in this issue is if someone is willing to debug it for me on their system. On my Windows installation, everything is working as expected.

Steps for debugging

1. Clone the repository
2. npm install the dependencies
3. In the debug panel, launch the extension (a new VS Code window should pop up)
4. In the original windows (where you launched the extension), put a breakpoint at src/yo/environment.ts#L48
5. Open the new window and launch the yo extension
6. The extension should stop at the breakpoint and in the debugpanel in the upper left corner, you have a variables panel. I'm very interested in the paths variable as those are all the locations that are searched for generators. (screenshot or copy-paste are fine)

A small extra would be to place a breakpoint at src/yo/environment.ts#L37 and copy-paste the result of the match variable.

It would really help me in debugging this bug.

[david-driscoll]

it has to do with how vscode (and atom) ship with their own version of node that it used to boot vscode. Those processes have a different npm path, and default environment variables than the typical node instance on a machine has. The best that can be done is to try and infer the best locations to find the folders.

That said it can vary wildly between computers, so it's a game of cat and mouse figuring out all the problems.

[SamVerschueren]

This might be related to https://github.com/sindresorhus/fix-path/issues/4

// @silverwind

[jhessin]

I don't know why this is still an issue we should just be able to do this to get our packages.

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

env.lookup( ()=> {
  generators = env.getGeneratorNames()
  // Do stuff with generators here.
}

Yeoman does this for us. Am I missing something?