CommonJS analysis gets confused for a bundled file

[bartlomieju]

Reported in: https://github.com/denoland/deno/discussions/23265#discussioncomment-9036006

Our CJS analysis gets confused by code like this:

/***/ "uuid":
/*!***********************!*\
  !*** external "uuid" ***!
  \***********************/
/***/ ((module) => {

module.exports = require("uuid");

/***/ }),

/***/ "stream":
/*!*************************!*\
  !*** external "stream" ***!
  \*************************/
/***/ ((module) => {

module.exports = require("stream");

/***/ }),

/***/ "zlib":
/*!***********************!*\
  !*** external "zlib" ***!
  \***********************/
/***/ ((module) => {

module.exports = require("zlib");

/***/ })

The CJS analysis in this case tells that zlib is a reexport (but not "uuid" or "stream"). I think this is completely wrong as it's not a reexport of the actual file, because it's inside a closure that provides module variable.

Complete file: https://gist.github.com/bartlomieju/a00a74d32947eef6a0811483d8619a0e

Reproduction in Deno:

import * as dicomStream from "@exini/dicom-streams-js";

$ deno run script.js

[jeremyBanks]

I encountered the same error in another module I was trying to use: contentful-management.

> deno
Deno 1.44.2
exit using ctrl+d, ctrl+c, or close()
REPL is running with all permissions allowed.
To specify permissions, run `deno repl` with allow flags.
> import "npm:contentful-management"
Uncaught TypeError: Could not find npm package 'zlib' referenced by 'contentful-management@11.27.3'.
    at async <anonymous>:1:22
>

I'm not sure whether it's the same root cause or not, and I'm not sure what package is actually the one importing zlib. When I try importing its dependencies directly, they don't cause the error, although one of them throws a different error:

> import "npm:type-fest@4.20.1"
Uncaught TypeError: Failed resolving package subpath for 'npm:type-fest@4.20.1' in '/home/jeremy/.cache/deno/npm/registry.npmjs.org/type-fest/4.20.1'.    
    at async <anonymous>:1:22

[dsherret]

@jeremyBanks I think that's a separate issue. It should be resolving zlib as node:zlib there.