How to fix "require is not defined"?

[DynamicArray]

I've used the preact template to create a test project with Snowpack. The first package I've added is jotai, but I immediately get an error.

Perhaps I've misunderstood, but I thought that converting commonjs files into esm was rolled into Snowpack. Is my config wrong? Or is there something odd about jotai that makes it not function?

Many thanks.
John

[FredKSchott]

Usually this happens when a package tells us that it's ESM but it then still contains CJS require() calls. If a package tells us it's ESM we'll trust it, but in some cases that's not true.

A quick look at jotai's ESM code seems fine (https://unpkg.com/browse/[email protected]/index.js) but then it imports use-context-selector, which does mix ESM & CJS: https://unpkg.com/browse/[email protected]/dist/index.modern.js

We can add a workaround for this specific package, but only if the package author is unresponsive. Can you file an issue with that repo for them to solve on their end? All Rollup projects would be affected by this issue and unable to use this package, so it's probably a bigger deal then they realize

[DynamicArray]

Fixed at the jotai end by @dai-shi. Thanks to both of you.

[joshuafcole]

I'm having a similar issue with the package fastpriorityqueue https://www.npmjs.com/package/fastpriorityqueue.

It's export is a single .js file with no dependencies, and the grand total of its CJS use appears to be:

if (require.main === module) {
  main();
}

module.exports = FastPriorityQueue;

Error:

Unhandled Runtime Error
Uncaught ReferenceError: require is not defined

Source
https://apollo.local:8080/web_modules/fastpriorityqueue.js [:289:1]
ReferenceError: require is not defined
    at https://apollo.local:8080/web_modules/fastpriorityqueue.js:289:1
    at createCommonjsModule (https://apollo.local:8080/web_modules/common/_commonjsHelpers-8c19dec8.js:14:5)
    at https://apollo.local:8080/web_modules/fastpriorityqueue.js:3:27

If I had to guess, either the complete lack of imports or the use of the relatively uncommon require.main might be tripping up the automatic ESM-ification process?

[dargue3]

Not to completely hijack this thread, but I'm getting the same problem when having just plopped in my old CRA app into a snowpack app. Running this code gives me the require not defined error:

if (env('SNOWPACK_PUBLIC_USE_MOCK_SERVICE_WORKER') === 'true') {
  const { browserWorker } = require('./testing/mocks/browser');
  browserWorker.start();
}

I'm assuming there's some sort of babel plugin that I'm missing here?

[FredKSchott]

in ESM (which Snowpack is designed for) you can't use the require() function in your own code. Instead, use await import()

[dotmilk]

Is there a way to tell snowpack, not to trust a package so it takes the needed steps to fix this?

[FredKSchott]

I'm not sure what you mean, by default we fail if the package mixes ESM and CJS code and they need to fix on their end

[xialvjun]

@FredKSchott I think dotmik was trying to say: we can have an option which tells snowpack to bundle it as commonjs module.

// snowpack.config.js
module.exports = {
  plugins: [],
  liers: ['jotai', 'fastpriorityqueue'], // both 'jotai' and 'fastpriorityqueue' are telling 'snowpack' they are ESM, but they are in fact mix ESM & CJS
};

[nrgapple]

@xialvjun Yes!

I am getting the same error for react-mapbox-gl

[mengbo-ji]

Agree with the above, I have seen this configuration in vite

[theseyi]

This would be very useful as Snowpack gains adoption, more people will run into this issue until a greater percentage of libraries move to truly support ESM.
Sometimes packages support ESM themselves, but they include dependencies that transitively have require calls. Some package authors or maintainers decide throw in the towel at this point since other bundlers are still able to support them, however, Snowpack imbues more a bit more trust than desired, and without an escape hatch it becomes very limiting.
Having the option to specify a fallback would be the best compromise here @FredKSchott

[mhamrah]

I was seeing this error when importing a grpc-web generated file with the commonjs option using typescript. The generated file uses require to load additional libraries. Couldn't figure out how to fix.

[gunters63]

I have a similar Problem.

I have some protoc-generated protobuf code (--js_out=import_style=commonjs) with grpc code generation (protoc-gen-grpc-web plugin with typescript support).

It generates a javascript and type file for the protobuf serialisation and a typescript file for grpc.

The files are here on gist:
processData_pb.js
processData_pb.d.ts
ProcessDataServiceClientPb.ts

In my source I can use the generated Types (with CRA) like this:

import { ReadResults, SubscribeRequest, TypeCode } from '../proto/gen/processData_pb';
import { GrpcProcessDataServiceClient } from '../proto/gen/ProcessDataServiceClientPb';

Already the first line crashes with snowpack start with

Uncaught SyntaxError: The requested module '../proto/gen/processData_pb.js' does not provide an export named 'TypeCode'

The Protoc documentation states:

Support for ES6-style imports is not implemented yet. Browsers can be supported by using Browserify, webpack, Closure Compiler, or similar to resolve imports at compile time.

Is there a workaround for this? At the moment that is a showstopper for me using Snowpack :(

[haruhihi]

I use rollup-plugin-re to transform require to import , and fixed it

rollup: {
      plugins: [
        require('rollup-plugin-re')({
          patterns: [
            {
              test: /require(\((["'])(?:\\\2|[^\n])*?\2\))/g,
              replace: 'import$1'
            }
          ]
        })
      ]

[gunters63]

I installed rollup-plugin-re and added those lines to snowpack.config.js packageOptions. I couldn't see any changes in the files generated by snowpack.

[haruhihi]

have you deleted the /node_modules/.cache folder and install again?

[tcodes0]

this does not seem to work

[rainmanhhh]

a workaround:
create your custom require(you can also create a define function and a Map to contain the required modules)

in index.ts

if (import.meta.env.MODE === 'production') {
  // eslint-disable-next-line @typescript-eslint/ban-ts-comment
  // @ts-ignore
  window.require = function(id: string): object {
    switch (id) {
      case './local/zh_CN':
        return {
          confirmLabel: 'OK',
          backspaceLabel: 'backspace',
          cancelKeyboardLabel: 'cancel keyboard'
        }
      default:
        return {}
    }
  }
}

[xialvjun]

@DynamicArray this one should be selected as the answer because even the right way is to tell the upstream to modify their code, the realistic way for us is just workaround it.

[Codigo-Fuentes]

I could not get this to work. Can you provide an example of an example with a define and map?

[mengbo-ji]

I also encountered the same problem，seek solution~~~!!!!!!!

[funkytek]

This works for me - make sure to delete node_modules/.cache after updating

const commonjs = require('@rollup/plugin-commonjs')

// ...

packageOptions: {
  polyfillNode: true,
  // convert mixed 'liar' packages from commonjs
  rollup: {
    plugins: [
      commonjs({
        include: [
          // packages
          'node_modules/filestack-react/**/*.js',
          'node_modules/filestack-js/**/*.js'
        ],
        // the mixing is the problem
        transformMixedEsModules: true
      })
    ]
  }
},

[funkytek]

UPDATE: this did not actually work for filestack-js. This superficially fixed the import problem so this may work for some cases but the library didn't function totally correctly. After looking at the package, it did have a browser module but it was not getting selected. Adding an "exports" section in the package.json worked, so I made this suggestion to the package owner. Workaround for similar situations in the meantime was to use an alias to force the selection of the correct bundle:

alias: {
  'filestack-js': 'filestack-js/build/browser/filestack.esm.js'
}