Uncaught TypeError: Error resolving module specifier “.prisma/client/index-browser”. Relative module specifiers must start with “./”, “../” or “/”.

Bug description
I have the following error message in my browser upon using sveltekit and the command  "npm run preview":
Uncaught TypeError: Error resolving module specifier “.prisma/client/index-browser”. Relative module specifiers must start with “./”, “../” or “/”.
It references a piece of code that was compiled with "npm run build" in localhost:3000/_app/start-b07b1607.js:
...s-d1fb5791.js";import".prisma/client/index-browser";let Be="",et="";function ...
How to reproduce
I have tried reproducing this error with using older versions of Prisma, the adaptor and Svelte, switching from pnpm to npm, but nothing helps. I have a MWE repository that comes close to reproducing the error but doesn't actually reproduce it at https://github.com/wvhulle/prisma-sveltekit-bug-report.
Expected behavior
How come the Svelte compiler emits “.prisma/client/index-browser” as a module specifier? Is this an error in Prisma, Vite or something else? The dev mode works without problem.
The question seems to be related, but is about Vue, not about Svelte.
Prisma information
I cannot share the schema, but this is the query that happens on the page where the error happens.
import prisma from '$lib/db';

export async function get() {
    const projects = await prisma.project.findMany({})
    return { body: projects }
}

And i am using this solution for the production build of Sveltekit:
import pkg, { PrismaClient } from '@prisma/client';
import { dev } from '$app/env';

declare global {
    var _prisma: PrismaClient; // eslint-disable-line
}

let prisma;
if (dev) {
    if (!global._prisma) {
        global._prisma = new PrismaClient();
    }
    prisma = global._prisma;
} else {
    const { PrismaClient: PrismaClientProd } = pkg;
    prisma = new PrismaClientProd();
}

export default prisma as PrismaClient; // type assertion for shim

Environment & setup

OS: Linux Mint 20.3
Database: PostgreSQL
Node.js version: v17.8.0

Prisma Version
prisma                  : 3.11.0
@prisma/client          : 3.11.0
Current platform        : debian-openssl-1.1.x
Query Engine (Node-API) : libquery-engine b371888aaf8f51357c7457d836b86d12da91658b (at ../../../../.pnpm-store/v3/tmp/_npx/69216/5/node_modules/.pnpm/@prisma+engines<EMAIL_ADDRESS>Migration Engine        : migration-engine-cli b371888aaf8f51357c7457d836b86d12da91658b (at ../../../../.pnpm-store/v3/tmp/_npx/69216/5/node_modules/.pnpm/@prisma+engines<EMAIL_ADDRESS>Introspection Engine    : introspection-core b371888aaf8f51357c7457d836b86d12da91658b (at ../../../../.pnpm-store/v3/tmp/_npx/69216/5/node_modules/.pnpm/@prisma+engines<EMAIL_ADDRESS>Format Binary           : prisma-fmt b371888aaf8f51357c7457d836b86d12da91658b (at ../../../../.pnpm-store/v3/tmp/_npx/69216/5/node_modules/.pnpm/@prisma+engines<EMAIL_ADDRESS>Default Engines Hash    : b371888aaf8f51357c7457d836b86d12da91658b
Studio                  : 0.458.0
Preview Features        : fullTextSearch

Thank you @wvhulle for the detailed issue 👍
I'll follow the progress as I'm in the same situation.
If I remember correctly, it's working well if you stay in endpoints, as soon as you go in the browser you have this issue. Temporarily I switch to any for now in this case. (A bit bad for a type lib)

@jycouet Hi, what do you mean with staying in the endpoints? I am trying to only call prisma in endpoints, but maybe it slipped through somehow. What do you mean with switching to any?

1⃣ Reproduce?
I cloned your repo but was not able to produce any error. you can with your reproduction repo?
Or you stripped out too many things?
2⃣ My issue was
I looked up in my git history, and I was wrong in my previous comment.
The issue was happening when I was importing enums like:
import { my_cool_enum } from '@prisma/client';
let data = my_cool_enum.ELEMENT1;

To overcome this, I need to do it like:
let data = 'ELEMENT1';

Maybe it's something similar that you have?
3⃣ Prisma client for dev & preview
I'm using this way to init my client and it's working well;
import Prisma, * as PrismaScope from '@prisma/client';
const PrismaClient = Prisma?.PrismaClient || PrismaScope?.PrismaClient;

export const PrismaClientKnownRequestError =
	Prisma?.Prisma.PrismaClientKnownRequestError || PrismaScope?.Prisma.PrismaClientKnownRequestError;
export const prismaInstance = new PrismaClient();
export default prismaInstance;

(Actually, I don't use the default export but directly prismaInstance. But this worked well also with your repo.)

No the issue was not in the MWE I gave. Okay I found it, there is a problem when you are using Prisma and import an enum type. Just like you said. Apparently I cannot import enums. The issue was in the fragment
import { Configuration } from '@prisma/client';
export function toObject(formData) {
	// console.log("formData", formData)
	const object: any = {};
	formData.forEach((value, key) => {
		console.log(`key: ${key}, value: ${value}`);
		if (value === "series") {
			object[key] = Configuration["series"]
		} else if (value === "parallel") {
			object[key] = Configuration["parallel"]
		} else if (!isNaN(Number(value)) && Number(value) !== undefined) {
			object[key] = Number(value)
		} else if (value !== "undefined" && value !== undefined && value !== "") {
			object[key] = value
		}
	}
	);
	return object
}

and more specifically  import { Configuration } from '@prisma/client';. I will use your advice and use let data = 'ELEMENT1'; if I want to reference an enum.

So you can easily add the issue in the repo?
And link this to https://github.com/sveltejs/kit/issues/4444?

It's not svelte-specific. I fot same issue with nuxt 3 in production build in heroku

It's not svelte-specific. I fot same issue with nuxt 3 in production build in heroku

its probably a vite, or rollup issue, i believe
maybe it's a problem with the generated package.json file in .prisma because resolving fails. idk, didn't test it
i will go test it in a bit, tell the results.

Problem
ok the problem is in @prisma/client import string is starting with .
Solutions

so first solution without editing the module files is this: https://github.com/prisma/prisma/issues/12504#issuecomment-1136126199
to fix it completely, @prisma/client should import .prisma/client with "../../.prisma/client" not ".prisma/client"

or .prisma should be renamed to something else, like _prisma

@DeepDoge Is it possible to get around the problem by adding an import map somewhere?

@DeepDoge Is it possible to get around the problem by adding an import map somewhere?

maybe, idk how vite or rollup would react to it. never used it before.

Some useful information about workaround.
I have a problem when you are trying to import a @prisma/client into a client-bundle. Despite the error, it makes little sense, because the prisma still can not work in the browser.
There is only one exception: Types. The prisma is difficult to tree-shaking, and if you import only one enum, it will try to include the whole @prisma/client in your bundle and runtime errors.
import { UserRoleEnum } from '@prisma/client'
// imported @prisma/client -> '.prisma/client' -> '@prisma/client/runtime/index'

The workaround is quite simple.

If you only need a type, then import enum as a type. This ensures that prism imports will only exist at compile time and will not be bundled.

// app.ts
import type { UserRoleEnum } from '@prisma/client'
type Props = { role: UserRoleEnum  }

If you want to use enum in runtime, here's a trick. In a separate file, you need to re-export the TYPE from the prism, but add an enum implementation for runtime.

// my-enums/user-role.ts

// Import original type
import type { UserRoleEnum as UserRoleEnumOrigin } from '@prisma/client'

// Guarantee that the implementation corresponds to the original type
export const UserRoleEnum: { [k in UserRoleEnumOrigin ]: k } = {
  Role1: 'Role1',
  Role2: 'Role2',
} as const

// Re-exporting the original type with the original name
export type UserRoleEnum = UserRoleEnumOrigin

// app.ts
import { UserRoleEnum } from 'my-enums/user-role.ts'

console.log(UserRoleEnum.Role1)
console.log(UserRoleEnum.Role3) // Property 'Role3' does not exist on type '{ Role1: "Role1"; Role2: "Role2"; }'.

This could have been avoided if the prisma had written all the enums in separate files. Then we could import a specific enum directly from the prisma without any problems
import { UserRoleEnum } from '@prisma/client/enums/UserRoleEnum'

I totally agree with @cawa-93 . I have the same issue when I use the enum in runtime which can't be imported as a type. I hope prisma team can make the client in separate files so that it is much easier to do tree shaking.

ok not the perfect solution but this works.
package.json
"prisma:inline": "cp ./node_modules/.prisma/client/*.js ./node_modules/@prisma/client",
"prisma:migrate": "prisma migrate deploy && npm run prisma:inline",
"prisma:migrate:dev": "prisma migrate dev && npm run prisma:inline",
"prisma:generate": "prisma generate && npm run prisma:inline"

just copy js files from .prisma/client to @prisma/client everytime you generate.

the workaround is simple by just setting the output path in prisma.scheme to node_modules/@prisma/client/ without any copying.
generator client {
  provider = "prisma-client-js"
  output   = "node_modules/@prisma/client/"
}

@shtse8 if my memory is not failing me, i tried doing that before sending my solution. it didnt work for me

ok not the perfect solution but this works.
package.json
"prisma:inline": "cp ./node_modules/.prisma/client/*.js ./node_modules/@prisma/client",
"prisma:migrate": "prisma migrate deploy && npm run prisma:inline",
"prisma:migrate:dev": "prisma migrate dev && npm run prisma:inline",
"prisma:generate": "prisma generate && npm run prisma:inline"

just copy js files from .prisma/client to @prisma/client everytime you generate.

the workaround is simple by just setting the output path in prisma.scheme to<EMAIL_ADDRESS>without any copying.
generator client {
  provider = "prisma-client-js"
  output   =<EMAIL_ADDRESS>}

remember primsa generate after updating @prisma/client package.

I've tried it, and it didn't work. If you would want to use this, you should set it to ../node_modules/[snip]. If I do that, it complains that @prisma/client did not initialize yet. Please run "prisma generate" and try to import it again.

The solution of @mawoka-myblock seems to be working indeed.
So just to recap:
in you schema.prisma use:
generator client {
    provider        = "prisma-client-js"
    output          =<EMAIL_ADDRESS>}

This will result in a folder structure like:
node_modules
|--@prisma
|--|--.prisma
|--|--|--client
|--|--client
prisma
|--schema.prisma

This way, export * from '.prisma/client' inside of<EMAIL_ADDRESS>can be resolved.

i got a solution and is working totally fine atleast for me. just add this to vite.config.ts
resolve: {
    alias: {
      ".prisma/client/index-browser": "./node_modules/.prisma/client/index-browser.js"
    }
  }

Note: This is not working with pnpm
this seems to work with any of the package manager even with pnpm.. a bit hacky but atleast works

import { createRequire } from "module";

const prismaPlugin = () => {
	const require = createRequire(import.meta.url);
	const pathName = require
		.resolve("@prisma/client")
<EMAIL_ADDRESS>"");

	return {
		name: "prisma-vite-plugin",
		config: () => ({
			resolve: {
				alias: {
					".prisma/client/index-browser": `${pathName}.prisma/client/index-browser.js`
				}
			}
		})
	};
};

export default defineConfig({
	plugins: [whatever(), prismaPlugin()],
});

// or without plugin
const require = createRequire(import.meta.url);
const pathName = require.resolve("<EMAIL_ADDRESS>"");

export default defineConfig({
	plugins: [whatever()],
        resolve: {
           alias: {
		".prisma/client/index-browser": `${pathName}.prisma/client/index-browser.js`
           }
       }
})

for vite + pnpm the following config works fine:
// vite.config.ts
export default defineConfig(({ mode }) => ({
   resolve: { alias: { '.prisma/client/index-browser': `@prisma/client/index-browser` } },
}))

Strange! Because i tried that one but it didn't worked. Are you using enums on frontend or not? 🤔

Note Sorry for my last assumption, I was wrong.

After serving the built index.html file with express, I encountered several errors due to the lack of access to enums from prisma. I tried your suggested solution but it didn't work because I am on Windows.
Therefore, I came up with a more generic solution that addresses the issue with the slashes in pathname. I hope it works on other operating systems, would you mind checking it on your setup?
// vite.config.ts
import { createRequire } from 'module'
import path from 'path'
import { defineConfig } from 'vite'

const require = createRequire(import.meta.url)

const prismaClient = require
   .resolve('@prisma/client')
   .replace(/@prisma(\/|\\)client(\/|\\)index\.js/, '.prisma/client/index-browser.js')

const prismaIndexBrowser = path.normalize(path.relative(process.cwd(), prismaClient))

export default defineConfig(() => ({
   resolve: { alias: { '.prisma/client/index-browser': prismaIndexBrowser } },
}))

Note Sorry for my last assumption, I was wrong.

After serving the built index.html file with express, I encountered several errors due to the lack of access to enums from prisma. I tried your suggested solution but it didn't work because I am on Windows.
Therefore, I came up with a more generic solution that addresses the issue with the slashes in pathname. I hope it works on other operating systems, would you mind checking it on your setup?
// vite.config.ts
import { createRequire } from 'module'
import path from 'path'
import { defineConfig } from 'vite'

const require = createRequire(import.meta.url)

const prismaClient = require
   .resolve('@prisma/client')
   .replace(/@prisma(\/|\\)client(\/|\\)index\.js/, '.prisma/client/index-browser.js')

const prismaIndexBrowser = path.normalize(path.relative(process.cwd(), prismaClient))

export default defineConfig(() => ({
   resolve: { alias: { '.prisma/client/index-browser': prismaIndexBrowser } },
}))

Sure I'll check it on morning. It's midnight and my laptop is off so I'll inform you if this works on Ubuntu or not 🙂

Can I ask, why is this still an issue one year on from the original bug report? Can the priority for this be bumped? Currently on 4.11.0. Thinking about Drizzle ORM at this point ...

Of course, you can ask, but the answer is pretty obvious: Because we had and have other things to do. We can only work on so many things, and this did not make the top of the list. If another tool gives you all you need, then of course you should use that.

Of course, you can ask, but the answer is pretty obvious: Because we had and have other things to do. We can only work on so many things, and this did not make the top of the list. If another tool gives you all you need, then of course you should use that.

Surely ongoing bugs and fixes should be priority for your users??

No, that is unfortunately not how it can work. There are an unlimited number of bugs with Prisma and all the other tools out there in the JS ecosystem. If we decided only to fix the known and reported bugs and problems, we would need to freeze feature development for a year or two - and that would clearly mean the death of Prisma. Fixing bugs and implementing new features is always something that has to be balanced.
This issue here has the problem that it does not actually contain a reproduction - so we at Prisma can not even understand and experience what is going on. The original message contains a link to a repository, but also mentions that it does not actually reproduce the problem. The original message mentions sveltekit, later messages Nuxt 3 and many have other comments have no information at all which of those they refer to or maybe something completely else.
Can you help out there @michealroberts?

I don't think its a bug on prisma. Vite does some stuffs while building for production and the prisma client couldn't be imported from node_modules/.prisma. There's no problem with webpack(so with next js) though

We tend to treat these as "bugs" as we want Prisma ORM to work with any other tool, in any configuration or situation. So if this is popular enough - and we actually have a reproduction we can look at - there is a high chance we might try to do something about it. And if it turns out to not be fixable from our sie, we might add some documentation on how to avoid the problem.

@janpio This is a good repo for reference: https://github.com/jaysoo/vite-prisma-barrel-exports

This?
$ tsc && vite build
src/App.tsx:4:9 - error TS2305: Module '"./test"' has no exported member 'UserType'.

4 import {UserType} from './test'

How is this related to what this issue is about?

Not quite, perhaps that repo is not quite the reproduction we're looking for. I haven't had time today to work on the reproduction repository, but I will have if ready soon.
We essentially need a vite frontend setup, and inside that setup if we import, e.g., Prisma and use Prisma.Decimal.isDecimal() it will show this error. For me, I was creating a tRPC transformer for handling decimals, and the same transformer is needed on the front end as the back end for type inference and serialisation to work correctly.
In issue I have found, is even if I import from a project that has prisma listed as a dependency into a vite project - I see this error. I can only import types that get stripped at compilation / build time.
I'll have more information soon.

Guys, appreciate all the work but vite is a MAJOR piece of software used by a lot of project. this is not an niche issue which affects several people.

Can you provide a reproduction for us @giladv that allows us to understand what is going on? As you can see in the previous messages, we don't have that yet.

Lots of people are having this problem, with the solution I found being so different from the other ones presented, I'm as baffled as everybody else but will share my experience debugging this in case it helps unearth some arcane glitch or identify a point that needs to be made clearer in the documentation, perhaps not even as a description of Prisma's behavior as much as a "tons of people get this wrong, here's a common pitfall to avoid" footnote. I spent this morning, yesterday, and the day before trying to figure out what was causing this issue for me. The issue:
npm run dev = runs flawlessly. Pushing to github → Vercel, with package.json scripts I tested in two configurations:
A
"build": "nuxt build",
"dev": "nuxt dev",
"generate": "nuxt generate && prisma migrate deploy && prisma generate",

B
"build": "nuxt build && prisma migrate deploy && prisma generate",
"dev": "nuxt dev",
"generate": "nuxt generate",

C
"build" "prisma migrate deploy && prisma generate && nuxt build"
...B

and no modifications of vercel's defaults, however, led to two pages breaking as pictured:

I am using Nuxt 3.3.2 and Prisma 4.12. I had this problem with two pages on my site not working, pages/.../pic/[picTitle] and /pages/tag/[tagName]. I have SSR set to false for tag/** and pic/**. Into the broken two pages, I was importing a couple validation functions from a file /types/models.ts that imported
import { Prisma } from "@prisma/client";
import { Art, BlogPost, Tag, TagsOnArt } from ".prisma/client";

and has a couple Prisma.validators to determine the types. I also exported a type-validating function from this file.
const blogPostWithTags = Prisma.validator<Prisma.BlogPostArgs>()({
  include: {
    tags: {
      include: {
        tag: true,
      },
    },
  },
});
export type BlogPostWithTags = Prisma.BlogPostGetPayload<
  typeof blogPostWithTags
>;

const artWithTags = Prisma.validator<Prisma.ArtArgs>()({
  include: {
    tags: {
      include: {
        tag: true,
      },
    },
  },
});
export type ArtWithTags = Prisma.ArtGetPayload<typeof artWithTags> & {
  url?: string;
  artists?: string[];
};
export function validateArtWithTags(obj: any): obj is ArtWithTags {
  if (
    typeof obj.title === "string" &&
    (!obj.info || typeof obj.info === "string") &&
    typeof obj.published === "boolean" &&
    Array.isArray(obj.tags)
  ) {
    return true;
  }
  return false;
}

I exported this blog type and another to a page that worked, and art types to a page that didn't. For some reason, although I have very similar logic between my blog post page and my art page, the art and tag pages were breaking yet not my blog. Weirder still is the tag description page, which wasn't working, uses a much simpler function:
export const validateTag = function (maybeTag: any): maybeTag is Tag {
  if (
    ["id", "name", "info"].every((property) =>
      Object.keys(maybeTag).includes(property)
    )
  ) {
    return true;
  }
  return false;
};

I tried messing with a lot of the page SFC typescript, since @Prisma and .prisma seemed likely culprits and the pages were what weren't working. But when I started to realize that there is magic happening between the two aforementioned prisma folders, and @Prisma is supposed to be the "official" library, which then exports stuff from the generated library, I wondered if at some step in the build, maybe at some point in building/generating process, code is being run in a context where it doesn't have the right access to certain references. One thing my two broken pages had in common, in contrast to my other pages using the code here, was that I was not just using exported types, but calling these functions. These are the only times that I'm executing code from this file, where Prisma.ArtArgs is referenced, with Prisma being imported from @prisma rather than .prisma. Perhaps at the time where vite (common between nuxt 3 and sveltekit) is building the page, it has lost or not yet made a connection between the @prisma npm package and generated code in .prisma. I suspect it's "not yet" because the deployment process involves clean installs and has to then generate stuff for @prisma to reference.
Testing this theory gave positive evidence. My pages are no longer broken (commit that fixed it) after simply copying and pasting what Intellisense generated to replace the validator functions and subsequent Prisma.ModelGetPayload<typeof modelValidator> convention that is suggested in the Prisma documentation. I didn't even have to change the type-validating function I was exporting after I
export type BlogPostWithTags = BlogPost & {
  tags: (TagsOnPosts & {
    tag: Tag;
  })[];
};
export type ArtWithTags = Art & {
  tags: (TagsOnArt & {
    tag: Tag;
  })[];
} & {
  url?: string | undefined;
  artists?: string[] | undefined;
};

What I think we collectively need a better understanding of and ramification explanation for is: what code one can access in what contexts at what stages of build/runtime. I didn't see anybody on this thread mention what order their build script Perhaps the documentation could suggest that developers use these validator functions to generate the types, but replace them the types generated by Intellisense. If you are using Prisma.[generated code] but you're importing from the npm package @prisma, it seems like one needs to be mindful of when the .prisma client is generated, which must happen for its generated features (e.g. Prisma.YourCustomModelArgs) to be usable by @prisma.
I also tested what would happen if I switch up the order of script commands (i.e. `"nuxt build && prisma generate" → "prisma generate && nuxt build") and reverted my code. This did not work!
Hopefully this helps somebody. If you're getting this error, look at whether there are files where the frontend might call code from files where you have:
import { Prisma } from "@prisma/client";
Prisma.[generatedCode]

Having the same issue with QwikJS

The way prisma generate the client is not nice

For me, this also happens with the edge client used for data proxy. The error message is a little bit different, but the hack from @sharmapukar217 works to fix it, provided you replace "index-browser.js" with "edge". I will post the error message here in case anyone else searches it up on the GH Issues filter:
The specifier “.prisma/client/edge” was a bare specifier, but was not remapped to anything. Relative module specifiers must start with “./”, “../” or “/”.

so big thanks to you @sharmapukar217! 🙏
You're welcome ❤

Just in case, I've managed to get a simpler version of that hacky ^ but working solution. That regex looked terryfing haha
// vite.config.ts
import { createRequire } from 'module'
import { relative, sep } from 'path'
import { defineConfig } from 'vite'

const { resolve } = createRequire(import.meta.url)

const prismaClient = resolve('@prisma/client/index-browser').replace(`@prisma${sep}client`, `.prisma${sep}client`)

export default defineConfig(() => ({
   resolve: { alias: { '.prisma/client/index-browser': relative(__dirname, prismaClient) } },
}))

Hey folks,
Is there anyone here that would be able to provide us with a small reproduction repository? It'd be really helpful for us to move this issue forward. Apologies in advance if someone posted one already, I might have missed it reading the entire thread.
Thanks a lot 🙏

Hi all! (specifically tagging @kuubson @sharmapukar217 @cappscolton @wvhulle)
Thank you for hopping in and helping folks! Could any of y'all provide a reproduction repo? We'd obviously like to make this experience better and/or update our docs with the suggested workarounds.
Thanks again!

As a data point, I ran into this issue today after upgrading both svelte, sveltekit and prisma. I downgraded Prisma to the latest 4.x version and switched from using pnpm to npm and the problem went away.

@danielimmke if you upgrade Prisma to 5.x but keep npm instead of pnpm, do you still have the issue?

@danielimmke not a problem at all, thank you for your help!

This was not an issue in my project using<EMAIL_ADDRESS>with<EMAIL_ADDRESS>I only upgraded vite to @4.4.7 and this issue appeared. Still w<EMAIL_ADDRESS>@kuubson 's workaround worked flawlessly for me, and is a simple workaround until the issue is resolved, probably from vite's end. Much thanks to them and the other helpers.

I tried upgrading prisma and prisma-clientand building with vite. No issue. Might be a PNPM caching thing.

vite 4.4.9, npm 9.8.1, prisma 5.1.1
not working out of the box (on production build). This workaround helps and everything works fine.
Tried deleting node_modules and dist/, no changes

This might be a difficult issue to reproduce because it might be a caching issue related to pnpm.
Using versions<EMAIL_ADDRESS><EMAIL_ADDRESS>and<EMAIL_ADDRESS>and after adding the alias workaround to my vite.config.ts, I was still experiencing the error when running Playwright component testing.
I thought to add the alias workaround to the playwright-ct.config.ts file, in the use.ctViteConfig.resolve.alias field, but it did not magically solve the problem like it did when I added it to my vite.config.ts to fix running dev and normal builds!
What did solve the problem for me though was keeping that configuration in my playwright-ct.config.ts, then:

Going to the component being tested that had an import from @prisma/client to import a database type, commenting out the import and replacing its usage with just built-in TS types
Running rm -rf node_modules && pnpm i
Running pnpm test-ct again (which for me runs playwright test -c playwright-ct.config.ts)
Since that worked without any issue, I went back to the component and uncommented the type import from the @prisma/client and updated the type back to normal
Running pnpm test-ct again worked now!

From my experience, when you have a magic fix like this where you remove things then add them back again and it fixes your problem, it is almost always a caching issue.

Yes I agree with Luke if you look at my follow up comment I didn't do have the issue when starting from scratch.

i got a solution and is working totally fine atleast for me. just add this to vite.config.ts
resolve: {
    alias: {
      ".prisma/client/index-browser": "./node_modules/.prisma/client/index-browser.js"
    }
  }

Note: This is not working with pnpm

Te amo

@danielimmke thanks for the info! Are you (or anyone else in this thread 😃 ) still having this issue? We believe that this should be resolved in 5.0 or later.

I can confirmed that this is not fixed/resolved in 5.0 or later. THis has been an issue for us running 5.3.1

We're having the same issue using Nuxt3 + prisma 5.3.1 so I can confirm the issue is still present.

I can confirm this is an issue in an express api using 5.3.1

@devi4nt @Chadyka do you have reproduction repos available? That would really help us understand what we missed in our fix. Any reproduction you can give us would be immensely helpful.

import { createRequire } from 'module'
import path from 'path'
import { defineConfig } from 'vite'

const require = createRequire(import.meta.url)

const prismaClient = require
   .resolve('@prisma/client')
   .replace(/@prisma(\/|\\)client(\/|\\)index\.js/, '.prisma/client/index-browser.js')

const prismaIndexBrowser = path.normalize(path.relative(process.cwd(), prismaClient))

export default defineConfig(() => ({
   resolve: { alias: { '.prisma/client/index-browser': prismaIndexBrowser } },
}))

This seems to have resolved the issue for me, so big thanks to you @sharmapukar217! 🙏

This worked for me, thanks @nickyhajal!
FWIW, I'm using prisma v5.3.1, no problems in dev but typeerror on local build and deploy to vercel. This fixed it.

FYI: The alias hack works with vite build, but not with vite preview.

ok not the perfect solution but this works.
package.json
"prisma:inline": "cp ./node_modules/.prisma/client/*.js ./node_modules/@prisma/client",
"prisma:migrate": "prisma migrate deploy && npm run prisma:inline",
"prisma:migrate:dev": "prisma migrate dev && npm run prisma:inline",
"prisma:generate": "prisma generate && npm run prisma:inline"

just copy js files from .prisma/client to @prisma/client everytime you generate.

this one works like a charm!!
I'm using SvelteKit on Vercel and it does work well on Vercel too

So, I got the same error and could not figure out what caused this out of nowhere.
Deleted the types I imported from prisma, etc etc etc
Then at my last breath of "If this doesn't fix it I quit" I found the issue:
Code affected:
import { PrismaClient } from '@prisma/client'

let client: PrismaClient | null = null
export default function () {
  if (!client) {
    client = new PrismaClient()
  }

  return client
}

If I change the line
let client: PrismaClient | null = null

To:
let client = null

I get the same error as mentioned
Maybe it helps someone find the root cause.
"@prisma/client": "^5.6.0",
"nuxt": "^3.8.1",
"node": "20.10.0"

resolve: { alias: { '.prisma/client/index-browser': path.relative(__dirname, prismaClientIndexBrowser) } },

This works like charm on vercel, pnpm

i got a solution and is working totally fine atleast for me. just add this to vite.config.ts
resolve: {
    alias: {
      ".prisma/client/index-browser": "./node_modules/.prisma/client/index-browser.js"
    }
  }

Note: This is not working with pnpm

This does work.
Though many people use .
'.prisma/client/index-browser': './node_modules/.prisma/client/index-browser.js',
I have to use @
'.prisma/client/index-browser'<EMAIL_ADDRESS>Also, pnpm run build works for me.

Any update on this? Still having issues.

 Simply importing anything in the same file as a Prisma.validator call from the client brings the entire thing to a halt with the following error in the browser (Firefox 121.0.1 AND Safari Version 17.1):
TypeError: The specifier “.prisma/client/index” was a bare specifier, but was not remapped to anything. Relative module specifiers must start with “./”, “../” or “/”.

The alias solution above works for me. I have created a minimum reproduction repo @jharrell
https://github.com/diericx/prisma-validator-issue
$ node --version
v21.5.0
$ sw_vers
ProductName:		macOS
ProductVersion:		14.1
BuildVersion:		23B73

Relevant package info:
{
  //...
  "prisma": "^5.8.1",
  "vite": "^5.0.12",
  //...
}
``

It's not svelte-specific. I fot same issue with nuxt 3 in production build in heroku

@cawa-93 FWIW, this is how I got it to work with Nuxt 3 / pnpm in nuxt.config.ts:
import { createRequire } from "module";

const prismaClientPath = createRequire(import.meta.url).resolve("@prisma/client");

// @see https://github.com/prisma/prisma/issues/12504#issuecomment-1365267088
export default defineNuxtConfig({
  vite: {
    resolve: {
      alias: {
        ".prisma/client/index-browser"<EMAIL_ADDRESS>".prisma/client/index-browser.js"),
      },
    },
  },
});

      ".prisma/client/index-browser": "./node_modules/.prisma/client/index-browser.js"

this worked for me.  thanks!

i got a solution and is working totally fine atleast for me. just add this to vite.config.ts
resolve: {
    alias: {
      ".prisma/client/index-browser": "./node_modules/.prisma/client/index-browser.js"
    }
  }

worked for me.  thank you!

i got a solution and is working totally fine atleast for me. just add this to vite.config.ts
resolve: {
    alias: {
      ".prisma/client/index-browser": "./node_modules/.prisma/client/index-browser.js"
    }
  }

Note: This is not working with pnpm

can confirm this works on nuxt 3. add it to nuxt.config.ts :
vite: {
  resolve: {
     alias: {
       ".prisma/client/index-browser": "./node_modules/.prisma/client/index-browser.js"
    }
  }
}

The standard solution does not work for me when updating to prisma and prisma-client to 5.13.0. It used to work before that.

i got a solution and is working totally fine atleast for me. just add this to vite.config.ts
resolve: {
    alias: {
      ".prisma/client/index-browser": "./node_modules/.prisma/client/index-browser.js"
    }
  }

Note: This is not working with pnpm

can confirm this works on nuxt 3. add it to nuxt.config.ts :
vite: {
  resolve: {
     alias: {
       ".prisma/client/index-browser": "./node_modules/.prisma/client/index-browser.js"
    }
  }
}

this works for me! after hours of searching, this solved the issue, allowing me to use Prisma in my remix 2.9.2 app. thanks @kiranimeid

I use pnpm and could not get any of the solutions above to work in my monorepo. I solved it like this, might help someone:

I have a local package with my prisma db @myproj/db.
I created another package called @myproj/db-browser.
Inside @myproj/db-browser I created index.ts with content like:

export type * from "@pinvites/db";
import { RoleEnum } from "@myproj/db";

export { RoleEnum };

I bundle the code above with esbuild. These are the dev and build script I added to @myproj/db-browser's package.json.

"scripts": {
  "build": "tsc --emitDeclarationOnly && pnpm exec esbuild ./src/index.ts --bundle --outfile=./dist/index.js --format=esm",
  "dev": "tsc -w --emitDeclarationOnly --incremental --preserveWatchOutput & pnpm exec esbuild ./src/index.ts --bundle --outfile=./dist/index.js --format=esm --watch"
},

In my apps that need to be bundled for browser I use @myproj/db-browser instead of  @myproj/db.

I use pnpm and could not get any of the solutions above to work in my monorepo. I solved it like this, might help someone:

I have a local package with my prisma db @myproj/db.
I created another package called @myproj/db-browser.
Inside @myproj/db-browser I created index.ts with content like:

export type * from "@myproj/db";
import { RoleEnum } from "@myproj/db";

export { RoleEnum };

I bundle the code above with esbuild. These are the dev and build script I added to @myproj/db-browser's package.json.

"scripts": {
  "build": "tsc --emitDeclarationOnly && pnpm exec esbuild ./src/index.ts --bundle --outfile=./dist/index.js --format=esm",
  "dev": "tsc -w --emitDeclarationOnly --incremental --preserveWatchOutput & pnpm exec esbuild ./src/index.ts --bundle --outfile=./dist/index.js --format=esm --watch"
},

In my apps that need to be bundled for browser I use @myproj/db-browser instead of  @myproj/db.

In my case (Node 20, Prisma 5.16),
line 110: "./*": "./*" in this file<EMAIL_ADDRESS> was causing the issue.
I replaced it with:
 "./generator-build/index.js": "./generator-build/index.js",    "./default.js": "./default.js",    "./index-browser.js": "./index-browser.js",    "./index.d.ts": "./index.d.ts",    "./runtime/library.js": "./runtime/library.js",    "./runtime/library.d.ts": "./runtime/library.d.ts",    "./runtime/binary.js": "./runtime/binary.js",    "./runtime/binary.d.ts": "./runtime/binary.d.ts",    "./wasm.d.ts": "./wasm.d.ts",    "./wasm.js": "./wasm.js",    "./edge.d.ts": "./edge.d.ts",    "./edge.js": "./edge.js",    "./react-native.d.ts": "./react-native.d.ts",    "./react-native.js": "./react-native.js",    "./extension.d.ts": "./extension.d.ts",    "./extension.js": "./extension.js".
And it works...

After updating to the latest prisma version i now get this error
Uncaught TypeError: The specifier “.prisma/client/default” was a bare specifier, but was not remapped to anything. Relative module specifiers must start with “./”, “../” or “/”.
Before updating this fix worked
const prismaClient = require
  .resolve("@prisma/client")
  .replace(
    /@prisma(\/|\\)client(\/|\\)index\.js/,
    ".prisma/client/index-browser.js"
  );

const prismaIndexBrowser = path.normalize(
  path.relative(process.cwd(), prismaClient)
);

export default defineConfig({
  plugins: [react()],
  envDir: "../../",
  resolve: {
    alias: [
      { find: ".prisma/client/index-browser", replacement: prismaIndexBrowser },

but now it doesn't anymore. do i just need to update /@prisma(\/|\\)client(\/|\\)index\.js/ with /@prisma(\/|\\)client(\/|\\)default\.js/ or is there something else?

NX monorepo, React + Express
Uncaught TypeError: Failed to resolve module specifier "@prisma/client". Relative references must start with either "/", "./", or "../".
index-browser? so loosing Express?

@kyle-belle
I solved this issue for myself.
It seems that after the prisma update, require.resolve('@prisma/client') returns a path ending in @prisma/client/default.js instead of the value @prisma/client/index.js which it was returning prior. There must have been a change to the @prisma/client package.json main property.
So what happens is the previous replace does not find the search string and ends up not replacing the value .prisma/client/index-browser.js. This then aliases .prisma/client/index-browser.js to @prisma/client/default.js which is not the intention.
My fix is to more liberally match @prisma/clientregardless of the main export file and substitute from there.
// vite.config.ts
const require = createRequire(import.meta.url)
const prismaClientDirectory = path.normalize(
  path.relative(
    process.cwd(),
    require.resolve('@prisma/client').replace(/@prisma(\/|\\)client(\/|\\).*/, '.prisma/client'),
  ),
)
const prismaIndexBrowserPath = path.join(prismaClientDirectory, 'index-browser.js')

...

resolve: {
    alias: {
      '.prisma/client/index-browser': prismaIndexBrowserPath,
    },
},

It's not svelte-specific. I fot same issue with nuxt 3 in production build in heroku

In Prisma docs about nuxt 3 there is a troubleshooting. They don't explain too much about this, it's a about vite route on client.
import { defineNuxtConfig } from 'nuxt'

export default defineNuxtConfig({
  modules: [
    '@prisma/nuxt',
  ],
  // additional config
  vite: {
    resolve: {
      alias: {
        '.prisma/client/index-browser': './node_modules/.prisma/client/index-browser.js',
      },
    },
  },
})

https://www.prisma.io/docs/orm/more/help-and-troubleshooting/help-articles/prisma-nuxt-module#resolving-typeerror-failed-to-resolve-module-specifier-prismaclientindex-browser

Fix for Vite ->
vite.config.ts
export default defineConfig({
    ...
    resolve: {
        alias: {
            '.prisma/client/index-browser': './node_modules/.prisma/client/index-browser.js',
        },
    },
});


Let formal blocks be inline link targets

Currently only pages and sections can do automatic linking. There have been a lot of requests to be able to link to arbitrary blocks. Issue #6 proposes letting formal blocks participate in automatic links, which will be a lot of work. This issue is for the simpler case of making formal blocks be inline link targets.

Bumping to Mallard 1.2

http://projectmallard.org/mep/mep0016


Functional difference between 2.4.0 and 3.2.0 on JsonSchema.Validate - can we get an obsolete tag?

Environment

Nuget Package: JsonSchema.Net
Nuget Version:  2.4.0 compared to 3.2
OS: Windows
.Net Target: .Net 6 (Azure Functions)

Describe the bug
In 2.4.0, there were 3 extension methods for JsonSchema.Validate:

One that has a JsonElement as the first parameter
One that has a JsonDocument as the first parameter
One that has a string as the first parameter

Our code was using the last extension method.
While 3.2.0 still has 3 extension methods for JsonSchema.Validate, we see that in the release notes on https://json-everything.net/json-schema for JsonSchema.Net that under the breaking changes for 3.0 that the one that accepted a string has been dropped:

One that has a JsonNode? as the first parameter
One that has a JsonDocument as the first parameter
One that has JsonElement as the first parameter

When we updated our NuGet package to use 3.2.0, our code compiled without any changes however all of our validations started failing with the following error: '#/type' 'Value is "string" but should be "object"'.  Several of our tests failed with this message.
It turns out that there was an implicit cast from our string to JsonNode? - which we missed initially as the code compiled but we noticed when trying to figure out what happened (ReSharper for the win).  We also see that this is documented on the release notes page "IMPORTANT Removal of this extension will only manifest at runtime. Code that called this extension method will still compile, but the validations will most likely fail."
However, it would be really nice if we could have that extension method back and have an obsolete tag added to that method.  This way, users of the library would get a warning during the compilation phase instead of at run time.
To Reproduce
Using 2.4.0, set up the following test:
string errorSchemaAsString = "{"$schema":"https://json-schema.org/draft/2020-12/schema#\",\"type\":\"object\",\"properties\":{\"Status\":{\"description\":\"Status object","type":"object","properties":{"Success":{"enum":[false]},"errors":{"description":"errors array","type":"array","maxItems":1}},"required":["Success","errors"],"$comment":"note the case sensitivity - errors (starts with lowercase e)"}},"required":["Status"]}";
string contentAsString = "{"Status": { "Success":false, "errors": [{ "Message" : "This is an error message" }] } }";
JsonSchema jsonSchema = JsonSchema.FromText(errorSchemaAsString);
ValidationResults validationResults = jsonSchema.Validate(jsonToValidate, new ValidationOptions
{
RequireFormatValidation = true,
ValidateAs = Draft.Draft202012,
OutputFormat = OutputFormat.Basic
});
Now, repeat the same test in 3.2.0 - see the differences.
Expected behavior
Expectation of the above code is that jsonSchema.Validate should not give an error in either 2.4.0 or 3.2.0.  Or the that the 3.2.0 codebase should tell us that we shouldn't use the string anymore to avoid the implicit cast.
Additional context
Please add back the extension method that took a string into the 3.x codebase and add a deprecation / obsolete tag to that extension method?  That way, people that are using the old extension method will get a compilation error and will know that they need to

I'm sorry, I had to remove this due to a conflict with the implicit cast from string to JsonNode?.  The resulting call becomes ambiguous and doesn't compile.
Your solution will be to add a single line of code before validation to parse the string into a node.
var node = JsonNode.Parse(text);

I explicitly mentioned this in the release notes for v3.0.0.

Thank you for the very quick reply - really appreciate it.
I saw it in the release notes which I checked before I went to do the upgrade, but I still missed the implication until our tests failed.
Since the code won't compile if both Extension methods are there, I understand that the obsolete tag won't be able to be added.
Thanks again.


RunBase vs SysOperation

May the point "Batch processing classes" be obsolete in favor of SysOperation classes?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: eaf8b5a7-5678-8263-16af-0bb35fc72f26
Version Independent ID: a28d68c0-313f-eab6-87c8-ffa3ce7a7125
Content: X++ classes and methods - Finance & Operations | Dynamics 365 | #MSDyn365FO
Content Source: articles/dev-itpro/dev-ref/xpp-classes-methods.md
Service: dynamics-ax-platform
GitHub Login: @RobinARH
Microsoft Alias: robinr

I can't see a mention of "Batch processing classes" in https://docs.microsoft.com/en-us/dynamics365/unified-operations/dev-itpro/dev-ref/xpp-classes-methods#batch-processing-classes
Batch processing classes are still used for batch processing: https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/sysadmin/batch-processing-overview

Well this bug is almost a year old already :)
The section does not even exists on the current version of the doc (not sure if that's the correct doc page when I found the issue originally), so I guess this can be clossed.
Thanks,
JA.


Expose 'path' parameter for store configuration.

I would like to use thanos store with 'path bucket lookup style' option from minio.
In minio code I see there is an assumption
https://github.com/minio/minio-go/blob/e55f8d731cb4343f4be9361525221d8752fa75a6/api.go#L308
	// Sets bucket lookup style, whether server accepts DNS or Path lookup. Default is Auto - determined 	// by the SDK. When Auto is specified, DNS lookup is used for Amazon/Google cloud endpoints and Path for all other endpoints. 	clnt.lookup = opts.BucketLookup
I am not sure why this option is the default one, but if it's an option it would be nice to have a way of setting it in thanos.
Minio client gives such option:
mc alias set s3 https://s3.dualstack.eu-central-1.amazonaws.com KEY SECRET --debug --path on
Possible options are on, off or auto
Because thanos does not expose that option via BucketConfig, when I am using AWS as a store minio sdk uses 'auto' option which in AWS case means path=off.
This is causing issues for us in one highly secured deployment where all traffic goes via customer firewall, where only static list of endpoints is possible (when path=on bucket name is part of host header, so host header is different for each bucket).
Also bucket names are leaking via DNS queries.
Describe the solution you'd like
We'd like to have new setting in store config:
bucket_lookup_type: on
Which would explicitly configure bucket lookup style.
Describe alternatives you've considered
After checking minio code
https://github.com/minio/minio-go/blob/e55f8d731cb4343f4be9361525221d8752fa75a6/pkg/s3utils/utils.go#L77
We see that if bucket name contains '.' path option is set to 'on'.
Indeed, problem does not occur for us if we use bucket names with a dot.
But we cannot ensure that this will always be the case (we do not own all buckets on our platform).
Additional context
https://docs.aws.amazon.com/AmazonS3/latest/userguide/VirtualHosting.html

After digging a bit deeper I began to suspect why "dns lookup style" became the default option in minio for AWS & GCP.
"Path based lookup" became deprecated some time ago by Amazon, but quickly that deprecation was reverted, because it became an issue for many customers.
https://aws.amazon.com/blogs/aws/amazon-s3-path-deprecation-plan-the-rest-of-the-story/
I think both option will stay with us for a bit longer moment so maybe it's still worth supporting setting that option explicitly in thanos. Especially that it's likely that AWS & GCP deprecation will be not in sync.
Absolute minimal patch that adds some support is:
diff --git a/pkg/objstore/s3/s3.go b/pkg/objstore/s3/s3.go
index 610ac6cf..aec30cd7 100644
--- a/pkg/objstore/s3/s3.go
+++ b/pkg/objstore/s3/s3.go
@@ -88,6 +88,7 @@ type Config struct {
 	PartSize    uint64    `yaml:"part_size"`
 	SSEConfig   SSEConfig `yaml:"sse_config"`
 	STSEndpoint string    `yaml:"sts_endpoint"`
+	BucketLookupType uint64 `yaml:"bucket_lookup_type"`
 }

 // SSEConfig deals with the configuration of SSE for Minio. The following options are valid:
@@ -248,6 +249,7 @@ func NewBucketWithConfig(logger log.Logger, config Config, component string) (*B
 		Creds:     credentials.NewChainCredentials(chain),
 		Secure:    !config.Insecure,
 		Region:    config.Region,
+		BucketLookup: minio.BucketLookupType(config.BucketLookupType),
 		Transport: rt,
 	})
 	if err != nil {

Even though there is some 'default setting logic' inside minio library. I think issue better fits thanos project, because there is no way to override it in thanos.

💪  It's reasonable. I think use S3ForcePathStyle as field name will better. aligning with the s3 sdk https://github.com/aws/aws-sdk-go/blob/v1.42.12/aws/config.go#L127


Value glitch double i2c

Hi,
I've added two HX711 sensors to my firmware config. See screenshot below. My report interval is every 2s. One input shows the value and updates it every 2s as expected. The other value jumps between 0 and the actual value. The firmware has been flashed on the RF-Star CC2652P2.
I suspect it has something to do with the shared I2C clock. If I physically unplug the first HX711 then the second value doesnt jump to 0 anymore.

I'm willing to compensate you, please contact me.

@TomasWeij I've tested this configuration. Please try to shift P21 and P13 down (to Output 4 & Output 5). Leave one unused Output 3 between sensors in the configuration. After this, you'll need to re-create a custom converter (if used).


Need a more basic example

I've had a look through the example apps and they are quite thorough and documented, but it would be really nice to have some very simple examples. I think the first example should be one that just serves a couple of static pages, then one that displays a form and then handles the submission.
I'm fairly new to Go and all I'm planning to build is a static site with a couple of forms, the validation example is the closest but I'm still going to be stripping bits out of it to get down to really basic example that I can then build up from.

Cancel this, I just found the walk through tutorial.
Putting the results from the walk through into the examples with a reference back to the tutorial would still be useful though.


iPhone X support

Hello,
I've just tested the app on an iPhone X and the bottom safe area is not considered:

I don't know if the version 1.1.1 of the original MiniTabBar fixed this, is there a specific reason why you forked it?
Thanks,
Dem

Hi,
Yes, I forked the project to be able to use it with Nativescript and perform some modifications and don't depend of the original project to be updated.
Thanks for report this issue, I think this will be fixed if I just update my project MiniTabBar so the only think that you need to do is remove the plugin and reinstall.
Probably this will be fixed tomorrow because today I'm really busy with some other stuffs.
I let you know when it's ready! 😄

@demetrio812 The new version 1.2.0 solve this problem 😄  Just update and enjoy!

Hello, thanks for that, unfortunately, this is what I see now:

Let me know if you need me to do some other test
Cheers,
Dem

Yes you need to delete your platforms/ios folder to get the lates version of the ios library

I did it, I also tried with the real iPhone X, it looks like there is a new version because the icons are up now, but not the text...
Will try again and let you know...
Thanks,
Dem

Try removing the platforms/ios and running this pod repo update to get the latest version of the MiniTabBar

It worked! I think the pod repo update made the trick! Thanks for the support!


I got key error in running ablate_squad.py

Hi, I have a problem training squad data
When I used mode paragraph or confidence, sharenorm, merge, sigmoid,
I got key error ‘b17/text-f1’ in trainer.py lind624.
How can I fix it?

There was naming error (although it should have still been working in paragraph mode). It should be fixed.


Bump main to 11.0.0~pre1

Branch ign-transport10 has been created for the Edifice release and 10.0.0 released from that.
The main branch now corresponds to version 11.0.0~pre1, and nightlies will soon be created from this branch.
https://github.com/ignition-tooling/release-tools/issues/421

I made a tweak in d04f97e.

CI is all :green_circle: