`validate` function breaks Next.js edge runtime

[TheEdoRan]

Hi, a user of next-safe-action reported a bug with the edge runtime, where the action execution breaks with this error when client input(s) get validated and parsed:

TypeError [ERR_VM_DYNAMIC_IMPORT_CALLBACK_MISSING]: A dynamic import callback was not specified.

I created a repo with a minimal reproduction of the issue, which appears to be directly related to TypeSchema validate function.

Now, apparently Vercel is abandoning edge rendering and I don't know if this "bug" is easily fixable, so please let me know if I can do something to help solving this one, if possible.

Here's the original issue opened in next-safe-action repo:

• [BUG] Schema parsing breaks in edge runtime TheEdoRan/next-safe-action#105

Thanks!

[decs]

hey, @TheEdoRan! thanks for investigating and reporting! I spent some time looking on this and learned that the Edge runtime has a limited API, which doesn't support dynamic imports (await import(...)).

The thing is that typeschema heavily relies on those to allow for optional peer dependencies. But while they're what make typeschema technically possible, bundler support can be a bit spotty, causing issues like this.

The best path forward long term would be to move away of dynamic imports. Though I haven't yet found a way to do it without setbacks to the developer experience and/or treeshaking. I'll leave this issue open for now and focus on an alternative for dynamic imports.

[TheEdoRan]

Though I haven't yet found a way to do it without setbacks to the developer experience and/or treeshaking.

Yeah, moving away from dynamic imports would probably result in a worse DX. As I said in the OP, though, Vercel is apparently abandoning edge runtime in favor of PPR (Partial Prerendering), which I think is much better; edge runtime has always been very limited and unpleasant to use, but that's just my take. Now, I don't know if this will ever happen, but I think they understood that it isn't really the best rendering/compute model going forward.

What I'll do with next-safe-action (at least for now) is export a copy of the "safe action client" instance from /zod path, that will just support Zod as validation library and use its schema parse function, then explain why and when this is needed in a troubleshooting section on the docs website. All this to say that in my opinion it's probably fine to keep dynamic imports for the better DX, and if some users experience problems related to TypeSchema, they can switch the import from / to /zod to use the lib without issues, with the only drawback of limited validation library support. I think it's a good compromise.

Please let me know your thoughts about this, and once again, thanks for your work with this amazing library @decs!