title: Why is my pre-built cloud foundry node app trying to fetch modules that are already in node_modules?
body: <p>I have a pre-built node app that must not attempt to access the network if <code>npm install</code> is run prior to startup - the intent is for everything to already be present in the <code>node_modules</code> directory. It is being deployed in a cloud foundry environment.</p>
  <p>This is not a proxy problem - there must be no attempt to access registry url's during cloud foundry app staging. I'm looking for ideas why it's trying to do this.</p>
  <p>When this app is deployed to cloud foundry, even though it detects the presence of the <code>node_modules</code> directory during staging, it still tries to retrieve basic dependency modules (like @node/types) that are already present in <code>node_modules</code>, and of course it times out trying to reach a registry that is not permitted in these environments. There are hundreds of other dependencies that it does not attempt to retrieve, but for some reason it thinks it does need some modules. For example:</p>
  <pre><code>   2021-03-17T16:29:57.71-0700 [STG/0] OUT        Installing any new modules (package.json + package-lock.json)
     2021-03-17T16:32:31.78-0700 [STG/0] OUT npm ERR! code ECONNREFUSED
     2021-03-17T16:32:31.78-0700 [STG/0] OUT npm ERR! errno ECONNREFUSED
     2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR! FetchError: request to https://&lt;registry-fqdn&gt;/@types%2flong failed, reason: connect ECONNREFUSED 10.x.x.x:443
     2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!     at ClientRequest.&lt;anonymous&gt; (/tmp/contents784086672/deps/0/node/lib/node_modules/npm/node_modules/node-fetch-npm/src/index.js:68:14)
     2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!     at ClientRequest.emit (events.js:315:20)
     2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!     at TLSSocket.socketErrorListener (_http_client.js:469:9)
     2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!     at TLSSocket.emit (events.js:315:20)
     2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!     at emitErrorNT (internal/streams/destroy.js:106:8)
     2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!     at emitErrorCloseNT (internal/streams/destroy.js:74:3)
     2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!     at processTicksAndRejections (internal/process/task_queues.js:80:21)
     2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!  FetchError: request to https://&lt;registry-fqdn&gt;/@types%2flong failed, reason: connect ECONNREFUSED 10.x.x.x:443
     2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!     at ClientRequest.&lt;anonymous&gt; (/tmp/contents784086672/deps/0/node/lib/node_modules/npm/node_modules/node-fetch-npm/src/index.js:68:14)
     2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!     at ClientRequest.emit (events.js:315:20)
     2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!     at TLSSocket.socketErrorListener (_http_client.js:469:9)
     2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!     at TLSSocket.emit (events.js:315:20)
     2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!     at emitErrorNT (internal/streams/destroy.js:106:8)
     2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!     at emitErrorCloseNT (internal/streams/destroy.js:74:3)
     2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!     at processTicksAndRejections (internal/process/task_queues.js:80:21) {
     2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!   type: 'system',
     2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!   errno: 'ECONNREFUSED',
     2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!   code: 'ECONNREFUSED',
     2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!   parent: 'app'
     2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR! }
     2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR!
     2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR! If you are behind a proxy, please make sure that the
     2021-03-17T16:32:31.79-0700 [STG/0] OUT npm ERR! 'proxy' config is set properly.  See: 'npm help config'
     2021-03-17T16:39:12.54-0700 [STG/0] OUT npm ERR! A complete log of this run can be found in:
     2021-03-17T16:39:12.54-0700 [STG/0] OUT npm ERR!     /home/vcap/.npm/_logs/2021-03-17T23_32_31_800Z-debug.log
     2021-03-17T16:39:12.56-0700 [STG/0] OUT        **ERROR** Unable to build dependencies: exit status 1
     2021-03-17T16:39:13.07-0700 [STG/0] ERR Failed to compile droplet: Failed to run all supply scripts: exit status 14
     2021-03-17T16:39:13.09-0700 [STG/0] OUT Exit status 223
     2021-03-17T16:39:13.28-0700 [STG/0] OUT Cell 5cee670a-6f6c-4510-a274-5584f197038c stopping instance 59dda306-be2f-4d08-830c-77c08ffab3f5
     2021-03-17T16:39:13.28-0700 [STG/0] OUT Cell 5cee670a-6f6c-4510-a274-5584f197038c destroying container for instance 59dda306-be2f-4d08-830c-77c08ffab3f5
     2021-03-17T16:39:13.76-0700 [API/1] ERR Failed to stage build: staging failed
  </code></pre>
  <p>Any ideas?</p>
  <p><strong>Edit #1</strong>
  Other facts:</p>
  <ol>
  <li>the app is pushed as a zip archive</li>
  <li>the zip file system includes the <code>node_modules</code> directory resulting from an <code>npm install</code> command run during the &quot;build&quot; to construct the zip</li>
  <li>the zip file system includes <code>package-lock.json</code> (from source)</li>
  <li>there is no <code>.cfignore</code> file anywhere in the zip archive</li>
  <li>the zip 'build' used to be taking place on a windows machine, and did not previously have this problem when subsequently pushed to cf</li>
  <li>the zip 'build' recently migrated to a gitlab ci runner from a k8s cluster, which may be using a centos-derived image</li>
  <li>the buildpack version is 1.7.32</li>
  <li>the version of node (14.14.0) on the build machine matches the version used by the buildpack, but the npm version (7.6.1) does not (buildpack uses 6.14.8)</li>
  <li>changing the build image where the zip is assembled to Ubuntu Bionic Beaver (18.04.4 LTS) makes no difference</li>
  </ol>