Failed to import - prisma

[open-cipher]

Failing module

• GitHub: https://github.com/prisma/prisma
• npm: https://www.npmjs.com/package/prisma

import { default } from 'https://esm.sh/prisma'

Error message

When I open the URL in my browser, I get the following export returned:

/* esm.sh - error */
throw new Error("[esm.sh] " + "yarn add [email protected]: yarn add v1.22.11\ninfo No lockfile found.\n[1/4] Resolving packages...\n[2/4] Fetching packages...\n[3/4] Linking dependencies...\nerror Could not write file \"/tmp/esm-build-92bbfb91d4805010a0281b45a9960da82bdde2c1/yarn-error.log\": \"ENOSPC: no space left on device, write\"\nerror An unexpected error occurred: \"ENOSPC: no space left on device, copyfile '/usr/local/share/.cache/yarn/v6/npm-prisma-3.1.1-4c13c35dd3a58af9134008c8ed0fdc21a632802c-integrity/node_modules/prisma/prisma-client/index-browser.js' -\u003e '/tmp/esm-build-92bbfb91d4805010a0281b45a9960da82bdde2c1/node_modules/prisma/prisma-client/index-browser.js'\".\ninfo Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.\n");
export default null;

Additional info

• esm.sh version: v47
• Deno version: 1.13.2

[ije]

i just clean the yarn cache, but i got another error, will look into it

/* esm.sh - error */
throw new Error("[esm.sh] " + "Could not resolve \"_http_common\" (Imported by \"prisma\")");
export default null;

[talentlessguy]

new error on v55:

/* esm.sh - error */
throw new Error("[esm.sh] " + "Unsupported nodejs builtin module \"worker_threads\" (Imported by \"@prisma/engines\")");
export default null;

related: denoland/std#1151

[josh-hemphill]

Looks like denoland/std#1151 has landed in the latest release of of deno/std

Now we're back to Could not resolve "_http_common" (Imported by "prisma") 😢

[josh-hemphill]

Looking into it, pretty sure _http_common is a javascript file internal to the node http module. Looking at the deno/std code, it seems to be supported, just unlisted since it's an internal.

[josh-hemphill]

Please see the issue I linked from prisma. I don't know if it was on purpose but trying to import just esm.sh/prisma is the prisma CLI. If you're trying to get the prisma client that would be esm.sh/@prisma/client.
Both of which are still failing. The CLI is still failing on worker_threads still for some reason even though deno_std added support for them.
The prisma client is failing on not being a able to resolve .prisma/client/index

[josh-hemphill]

After looking into it more, I don't think the prisma CLI will ever be able to be converted since it relies on specifics on Node's interactions with the terminal, I'm also not sure you'd want to, since the CLI should only be installed on dev machines to generate a client; and the @prisma/client only re-exports a local .prisma/client directory that the CLI generated. So the issue doesn't really lie with esm.sh, Prisma will have to make it possible to generate a Deno-compatible client and/or fix some issues with it so that you can create a deno bundle with the node modules substituted.
I would opt to close this issue since I don't see any way esm.sh can do anything for this.

[ije]

@josh-hemphill i don't know, i'm not the user of prisma, seem it is not CDN friendly

[josh-hemphill]

Yeah, my point was that it would be kind of pointless to try and use prisma via esm.sh or any CDN.
The client is actually generated from your local project using the cli, and the cli would require a specific install script to support deno install, so esm.sh is working as intended here.
That's why I'm advocating for closing this out, unless there's a way to mark the package with a warning for deno users since they're probably misunderstanding what package they need, and should be looking to the prisma code generator to provide support for deno.

[open-cipher]

After looking into it more, I don't think the prisma CLI will ever be able to be converted since it relies on specifics on Node's interactions with the terminal, I'm also not sure you'd want to, since the CLI should only be installed on dev machines to generate a client; and the @prisma/client only re-exports a local .prisma/client directory that the CLI generated. So the issue doesn't really lie with esm.sh, Prisma will have to make it possible to generate a Deno-compatible client and/or fix some issues with it so that you can create a deno bundle with the node modules substituted. I would opt to close this issue since I don't see any way esm.sh can do anything for this.

apologies for the late reply. I agree with @josh-hemphill, the prisma cli or generated client will have to internally add support for deno, since they rely mostly on generating code files as a post installation step.