Node package resolution bundling error
I just used this
api
package (https://github.com/readmeio/api) to generate a local npm package containing an API client for a service I'm using, which is based I guess on an OpenAPI spec. Initially it worked fine, but after restarting my Convex dev server, I'm now seeing a bunch of errors like the following:
See https://api.readme.dev/docs/how-it-works for details on how this api
package functions/what it does.12 Replies
Is that running in Convex's runtime or Node.js? Seems it does import from "fs" which will only work in Node.js environment.
As of why it was working and then suddenly stopped, no idea, why it worked in the first place. Perhaps something even small in the source changes where this path is not pruged from the tree anymore or something.
This failure occurs during the bundling process, I think—while "Preparing Convex functions"
I hadn't added the
"use node";
directive yet to the one action that is using this, but just did and am observing the same result
Figured it wasn't relevant but just wanted to share as much info as possibleHm... that is weird. The bundle failing if you don't bundle for node is expected. Can you confirm the "use node" directive is processed correctly by running
npx convex dev -v
If the function is only bundled for node, the error should only show up after you see Queries and mutations modules:
. This is the modules bundled for Convex's runtime. If the error shows before that it hints to the fact that this path is somehow still bundled for Convex's runtime.Ok, bundling actually works if I add
"use node";
to the top of the file which imports the module with the Node dependency, in addition to adding "use node";
to the file which exports the action.
In other words, I have a file A
which imports this generated API client, which has Node dependencies, and which exports some code (but not any actions) to file B
, which actually exports an action. I need "use node";
in both in order for bundling to succeed.
This was a surprise to me; I thought I only needed to include "use node";
in the files which export actions.
But in any case, it seems to be resolved!Hmm.. yeah, that is surprising. You're right that "use node" only matters in files that export functions. Does the file which imports the module export any other functions like queries and mutations by any chance? That would explain what you are seeing.
Nope, it doesn't export any Convex functions, nor do its dependencies
Hmm... that is strange. Just so I make sure I can track down the problem and fix it on our side for the future. Can you run
npx convex dev -v
and confirm if file A (the one that depends on Node.js but has no function exports) appear in "Node modules" list. If it does, it means the cli believes (perhaps incorrectly) it exports some query, mutation or action, which is why we require it to have "use node". If it doesn't, then "use node"; shouldn't matter and is puzzling why it does.It does appear there (the file in question is named
withOrderful
):
@presley let me know if you want me to DM you the contents of that file and/or its local file dependencies@RJ is this file being imported from multiple places? The bundling method is determined by the entry point (the file like convex/foo.ts) but if another file like
convex/bar.ts
does not have "use node";
in it, then this code would be bundled both ways.middleware/withOrderful
is only imported by one file—an action which has the "use node";
directive at the top. Double-verified by checking language-server references and by performing a project-wide grep!
middleware/withOrderful
does import files which are themselves imported by other Convex functionsYeah, sorry. I think I misread how we find entry points. We consider every file in
convex
as an entry point. And this file doesn't evaluate if you don't have "use node";
So what you are seeing does make sense. You need "use node" on all files in your convex dir that depend on node, not only the ones that export functions. I will update the doc to make it more clear.Oh I see, gotcha! No bugs here, then 🙂 Thanks!