Monorepo setup fs/promises

[florianbepunkt]

Using this lib in a larger NPM monorepo setup, gives me the following error:

It seems that fs/promises is not polyfilled.

Any ideas how to resolve this / make it work?

  jsx-email/cli Command Name: `preview` +0ms
The CJS build of Vite's Node API is deprecated. See https://vitejs.dev/guide/troubleshooting.html#vite-cjs-node-api-deprecated for more details.

  🚀 jsx-email Preview

  ➜  Local:   http://localhost:55420/
ENOTDIR: not a directory, open '/Users/florianbischoff/Repositories/jarvis-next/node_modules/node-stdlib-browser/cjs/mock/empty.js/promises'
✘ [ERROR] Could not read from file: /Users/florianbischoff/Repositories/jarvis-next/node_modules/node-stdlib-browser/cjs/mock/empty.js/promises

    ../../../mongodb/lib/client-side-encryption/state_machine.js:4:19:
      4 │ const fs = require("fs/promises");
        ╵                    ~~~~~~~~~~~~~

6:52:50 PM [vite] error while updating dependencies:
Error: Build failed with 1 error:
../../../mongodb/lib/client-side-encryption/state_machine.js:4:19: ERROR: Could not read from file: /Users/florianbischoff/Repositories/jarvis-next/node_modules/node-stdlib-browser/cjs/mock/empty.js/promises
    at failureErrorWithLog (/Users/florianbischoff/Repositories/jarvis-next/node_modules/jsx-email/node_modules/vite/node_modules/esbuild/lib/main.js:1649:15)
    at /Users/florianbischoff/Repositories/jarvis-next/node_modules/jsx-email/node_modules/vite/node_modules/esbuild/lib/main.js:1058:25
    at /Users/florianbischoff/Repositories/jarvis-next/node_modules/jsx-email/node_modules/vite/node_modules/esbuild/lib/main.js:1525:9
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
^C

[shellscape]

This probably doesn't have much to do with the fact you're in a monorepo. If I had to guess, mongodb is being imported somewhere in a server component. And that is being transitively imported into an email component. Are you using this in a Next.js project with a server and client deployment by chance?

[florianbepunkt]

No, I'm not using NextJS. I investigated the issue... basically there are two things going wrong:

1. Incomplete polyfill
The issue would happen with any non-browser compatible module. You currently prevent this for most people in your lib by polyfilling node internals with a Vite plugin. But the polyfill you are using, does not support fs/promises, only fs (I guess the same is true for the other node:std/promises packages).

It would be the easiest solution if all Node internals would be polyfilled. It kind of defeats one of the main monorepo purposes if I have to undo code-colocation...

2. Tree-shaking
The tree-shaking is off for the preview (building works fine). Not sure why that is. Mongodb is not imported directly. The scenario is this:

Package A exports two things: 1. mongoClient, 2. a browser-compatible pure function I need in my template
Package B is where the email template lives. It imports the pure function from package A.

Since both are ESM, this should not be a problem. But apparently it is.

Workaround:

In package a, I created a browser export, which is favored by Vite when bundling for frontend. So package A looks like this:

{
  "name": "@monorepo/package-a",
  "exports": {
    ".": {
      "node": "./dist/src/index.node.js", <-- this is used by other node modules that import this package
      "types": "./dist/src/index.node.d.ts",
      "import": "./dist/src/index.browser.js" <-- here I only export browser compatible functions
    }
  },

[shellscape]

Great triage, thanks for doing that. I've been thinking a lot about the problem.

In a branch testing out some reports about edge function bundling problems, I realized that our esbuild usage for prebundling templates for rendering was being greedy and not marking dependencies as external. When I changed that, the output size of a prebundled template dropped dramatically (10x) for some templates in the demo. Last night I got to wondering if that change would affect treeshaking during vite dev, and I think it might.

Would you be up for testing a test build with your setup without the workaround?

[florianbepunkt]

If you can wait a bit, sure. My son is about to be born, so hard to make promises right now :D

[shellscape]

Oh man, congratulations!! Absolutely this can wait!