Generator trails fails to install when behind corporate proxy

[animedbz16]

Opening this up over here per https://github.com/trailsjs/generator-trails/issues/60#issuecomment-231368947

I've had a little bit more time to investigate this which I orginally reported here:
trailsjs/trails#210

When dumping the options that are passed into the got library, it seems that this generator module is attempting to directly call out to npm itself for installation, which doesn't use my proxy environment.

[user@localhost trails-app]$ yo trails

Get ready to blaze a new Trails Application!

Checking for updates...
? Choose a Web Server express
? What express version do you want to use ? 5
? Choose an ORM mongoose
? Do you want to use Footprints (automatic REST API from models) ? Yes
? Module Name trails-app
Opts =>   { protocol: 'https:',
  path: '/trails-app',
  retries: [Function: backoff],
  slashes: true,
  auth: null,
  host: 'registry.npmjs.org',
  port: null,
  hostname: 'registry.npmjs.org',
  hash: null,
  search: null,
  query: null,
  pathname: '/trails-app',
  href: 'https://registry.npmjs.org/trails-app',
  method: 'HEAD',
  headers: 
   { 'user-agent': 'got/6.3.0 (https://github.com/sindresorhus/got)',
     'accept-encoding': 'gzip,deflate' },
  followRedirect: true }


RequestError: socket hang up
    at ClientRequest.req.once.err (/home/user/.nvm/versions/node/v6.3.0/lib/node_modules/generator-trails/node_modules/npm-name/node_modules/got/index.js:67:21)
    at ClientRequest.g (events.js:286:16)
    at emitOne (events.js:96:13)
    at ClientRequest.emit (events.js:188:7)
    at TLSSocket.socketErrorListener (_http_client.js:308:9)
    at emitOne (events.js:96:13)
    at TLSSocket.emit (events.js:188:7)
    at emitErrorNT (net.js:1272:8)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    at process._tickCallback (internal/process/next_tick.js:98:9)

events.js:160
      throw er; // Unhandled 'error' event
      ^
RequestError: socket hang up
    at ClientRequest.req.once.err (/home/user/.nvm/versions/node/v6.3.0/lib/node_modules/generator-trails/node_modules/npm-name/node_modules/got/index.js:67:21)
    at ClientRequest.g (events.js:286:16)
    at emitOne (events.js:96:13)
    at ClientRequest.emit (events.js:188:7)
    at TLSSocket.socketErrorListener (_http_client.js:308:9)
    at emitOne (events.js:96:13)
    at TLSSocket.emit (events.js:188:7)
    at emitErrorNT (net.js:1272:8)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    at process._tickCallback (internal/process/next_tick.js:98:9)

[animedbz16]

Maybe this is an upstream issue since this project is forked, but I'm not entirely sure.

[matthewwiesen]

Just ran into this same issue but running on latest node v7.0.0 and latest yo / generator-trails and seem to run into the same issue here:

[user@localhost trails-test]$ npm ls -g --depth=0
/home/user/.nvm/versions/node/v7.0.0/lib
├── [email protected]
├── [email protected]
└── [email protected]
[user@localhost trails-test]$ yo trails

Get ready to blaze a new Trails Application!

Checking for updates...
? Choose a Web Server express
? What express version do you want to use ? 5
? Choose an ORM mongoose
? Do you want to use Footprints (automatic REST API from models) ? Yes
? Module Name trails-test


RequestError
    at ClientRequest.req.once.err (/home/user/.nvm/versions/node/v7.0.0/lib/node_modules/generator-trails/node_modules/npm-name/node_modules/got/index.js:81:21)
    at ClientRequest.g (events.js:291:16)
    at emitOne (events.js:96:13)
    at ClientRequest.emit (events.js:188:7)
    at TLSSocket.socketErrorListener (_http_client.js:309:9)
    at emitOne (events.js:96:13)
    at TLSSocket.emit (events.js:188:7)
    at emitErrorNT (net.js:1281:8)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    at process._tickCallback (internal/process/next_tick.js:98:9)

events.js:160
      throw er; // Unhandled 'error' event
      ^
RequestError
    at ClientRequest.req.once.err (/home/user/.nvm/versions/node/v7.0.0/lib/node_modules/generator-trails/node_modules/npm-name/node_modules/got/index.js:81:21)
    at ClientRequest.g (events.js:291:16)
    at emitOne (events.js:96:13)
    at ClientRequest.emit (events.js:188:7)
    at TLSSocket.socketErrorListener (_http_client.js:309:9)
    at emitOne (events.js:96:13)
    at TLSSocket.emit (events.js:188:7)
    at emitErrorNT (net.js:1281:8)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    at process._tickCallback (internal/process/next_tick.js:98:9)

Edit:
Pinging @tjwebb since it seems this issue hasn't had much feedback on this.

[tjwebb]

I'm really not sure what to do here. Do other npm installations work fine? This generator isn't doing anything special that npm isn't already doing.

[tjwebb]

Spent some time doing some research after I posted that ^^

In addition to just doing an npm install, the generator is also using npm-name to check whether a module exists in the npm registry. npm-name depends on a module called got, in which your proxy problem exists: sindresorhus/got#79

I tried to make a quick case for including this feature in node core: nodejs/node#8381 (comment). In the meantime, I'll take a closer look at generator-node to see if there's some way we can either a) respect proxy settings, or b) avoid this npm-name thing altogether.

@matthewwiesen @animedbz16 thoughts?

[matthewwiesen]

Been a while since I looked at this, but after reading through those issues, it seems to describe this issue here in better detail and does seem to be an upstream issue that is ultimately affecting trails via the dependency tree.

I agree that the proxy environment is specific to the user's environment and that ultimately this should be something that is respected and preserved as many other executables do this such as NPM when we run 'npm install' that respect the proxy.

I'll leave a comment upstream as well to provide my feedback and thoughts since ultimately this creates confusion downstream trying to debug things and causes inconsistency as many modules handle this differently. I agree that this should likely be handled directly within node core.