remix: Not able to deploy on Fly via Docker: `top-level await` error

What version of Remix are you using?

v1.14.0

Are all your remix dependencies & dev-dependencies using the same version?

Steps to Reproduce

Deploy to Fly using Docker

Expected Behavior

Build should succeed

Actual Behavior

Build step is failing:

#17 [build 6/6] RUN npm run build
#17 14.11 ✘ [ERROR] This require call is not allowed because the imported file "node_modules/@jspm/core/nodelibs/browser/worker_threads.js" contains a top-level await
#17 14.11 
#17 14.11     node_modules/@prisma/client/runtime/index.js:13:8230:
#17 14.11       13 │ ...ssageOnPort:LR}=require("worker_threads"),xR=["GET","HEAD","POS...
#17 14.11          ╵                            ~~~~~~~~~~~~~~~~
#17 14.11 
#17 14.11   The top-level await in "node_modules/@jspm/core/nodelibs/browser/worker_threads.js" is here:
#17 14.11 
#17 14.11     node_modules/@jspm/core/nodelibs/browser/worker_threads.js:97:49:
#17 14.11       97 │ ...rkerData, environmentData }] = await once(parentPort, 'message'));
#17 14.11          ╵                                   ~~~~~
#17 14.11 
#17 14.11 
#17 14.11 ✘ [ERROR] This require call is not allowed because the imported file "node_modules/@jspm/core/nodelibs/browser/worker_threads.js" contains a top-level await
#17 14.11 
#17 14.11     node_modules/@prisma/client/runtime/index.js:56:58637:
#17 14.11       56 │ ...MessagePort:SU}=require("worker_threads"),uA,WA=class extends E...
#17 14.11          ╵                            ~~~~~~~~~~~~~~~~
#17 14.11 
#17 14.11   The top-level await in "node_modules/@jspm/core/nodelibs/browser/worker_threads.js" is here:
#17 14.11 
#17 14.11     node_modules/@jspm/core/nodelibs/browser/worker_threads.js:97:49:
#17 14.11       97 │ ...rkerData, environmentData }] = await once(parentPort, 'message'));
#17 14.11          ╵                                   ~~~~~
#17 14.11 
#17 14.11 
#17 14.15 ERROR: "build:remix" exited with 1.

About this issue

Original URL
State: closed
Created a year ago
Reactions: 3
Comments: 17 (1 by maintainers)

Most upvoted comments

It seems like Remix is suddenly importing files that used to be tree-shaken out of the browser build. In my other project, Sentry was also getting included despite never being used client-side. This may be specific to this kind of import: import * as Sentry from "@sentry/node";

I think Remix needs a few things to put these issues to rest:

A way to audit what is being included in the client build without fishing around in the bundles (I’m thinking a tree-like output, that shows the module import graph)
A warning when a bare module specifier ends up in the client, like "fs" or other known server runtime prefixes, like "node:*"
A fix for what appears to be a regression that occurred sometime between 1.13 and 1.16 (I think 1.14 introduced it) that led to extra things in the client bundle
Bonus points: A Remix config option to specify dependencies and files that should never be seen in the browser build. Either warn or fail the build. Maybe something like serverOnlyImports: [ "@org/package", "**/server-code/**" ]

nakleiderer on May 19, 2023

I had the same problem and solved it by migrating some deprecated @prisma/client/runtime imports in my app to @prisma/client/runtime/library.

If you get this during startup:

imports from "@prisma/client/runtime" are deprecated.
Use "@prisma/client/runtime/library",  "@prisma/client/runtime/data-proxy" or  "@prisma/client/runtime/binary"

It might also work for you.

fiws on May 22, 2023

I was able to circumvent the issue with an npm override:

"overrides": {
    "@remix-run/dev": {
      "esbuild-plugin-polyfill-node": "0.1.0"
    }
  }

nakleiderer on May 17, 2023

Ok, thank you for all the help… I deleted everything in my routes until it was just and index, root, and entry.x files For me it seems it is an my session.server.ts which i moved into a “package” in my monorepo then imported poorly.

I basically couldn’t narrow it down to just one thing… but basically if my mono-repo packages bleed any node dep than it borked. Basically treeshaking was working or i missed something.

for me i re-exported all my monorepo packages in a file like utils/[package].server

export * from `@monorepo/[package]`;

i wish i could just mark packages as server only.

bvkimball on May 18, 2023

Looks like another issue popped up and it might be related to the overrides that I tried:

caught TypeError: Failed to resolve module specifier "buffer". Relative references must start with either "/", "./", or "../".

This error persists even with no routes, so it appears to be including node polyfills in the browser build. I’m not sure if this is actually related to the override or not since I can’t build without that override.

nakleiderer on May 17, 2023