indirect access of 'require'

[piotrromanowski]

when trying to use https://github.com/SheetJS/sheetjs
you run into the following error.

node_modules/xlsx/jszip.js:25:135: error: "require" must not be called indirectly

...ts;return (function e(t,n,r){function s(o,u){if(!n[o]){if(!t[o]){var a=typeof require=="function"&&require;if(!u&&a)return a(o,!0);if(i)return i(o,!0);throw new Error("Cannot find module '"+o+"'")}var f=n[...

                                                                                                      ~~~~~~~

Is it intentional? Currently getting around this issue by hosting a copy of the dependency without the typeof require == 'function' calls, but it would be nice if the library allowed those checks

Let me know if there's anything I can do to help! I can possibly dig in and make the exception for this case somewhere here

esbuild/src/esbuild/parser/parser.go

Line 7573 in db7fd2b

if e.Ref == p.requireRef && (e != p.callTarget && e != p.typeofTarget) {

[evanw]

This is a similar issue to #56, and is intentional.

Bundling with esbuild is intended to traverse your whole dependency tree and include all of your dependencies in the bundle. However, it can only do this if the dependency tree is statically analyzable. This is why esbuild needs every use of require to be a call expression with a string argument. Capturing the value of require and using it indirectly like this is not statically analyzable.

[evanw]

One possibility could be to change this into a warning (either by default or as an option). That would allow the build to continue and generate the bundle. The call to require wouldn't work though. It would crash if it was ever used. I believe that would be sufficient to fix this particular library, which was bundled very strangely.

[piotrromanowski]

Hmm I'm not it's the same case here is it? The code in this file never actually calls require with any arguments that aren't statically analyzable, I think making it a warning would fix the issue.

https://raw.githubusercontent.com/SheetJS/sheetjs/master/jszip.js

Though I agree that this is very strange

[prantlf]

The warning could hide the actual error. Did you try bundling the module delivered by NPM? Instead of bundling UMD modules intended for loading by the browser directly, you can install dependencies like jQuery or JSZip via NPM and let esbuild decide for their most suitable output using their package definition. For example:

npm i jszip

And in your code:

import JSZip from 'jszip'
window.JSZip = JSZip // if some code neds the global variable

This is how I included JSZip in my source module.

[evanw]

This should be fixed in version 0.5.3. It turns out the problem was specifically caused by code bundled with Browserify, so I have special-cased this code pattern in esbuild. You can read more in the release notes.

[atomkirk]

@prantlf how did you fix this?

 > node_modules/jszip/lib/readable-stream-browser.js:9:25: error: Could not resolve "stream" (set platform to "node" when building for node)
    9 │ module.exports = require("stream");
      ╵                          ~~~~~~~~

1 error

[geoffharcourt]

@atomkirk that seems like something that appeared in 0.11.16. You should downgrade to 0.11.15 and it should go away. (I am trying to work up a bug report for it, but don't have enough info yet.)

Here's the issue I opened to discuss or resolve this: #1220