Wasp-lang•3mo ago

Referencing entities via enums

Hello, though there is support for creating enums in schema.prisma, it does not look like there is a regular way to access them from JS/TS code as they don't seem to be exported as wasp entities in wasp/entities. For example, I've defined this enum: enum OneToOneMeetingStatus { SCHEDULED COMPLETED POSTPONED CANCELLED } It has been successfully created via migration, but when I try to import it into my code, I get this error '"wasp/entities"' has no exported member named 'OneToOneMeetingStatus'. Did you mean 'OneToOneMeeting'? I could not find any reference in the documentation

25 Replies

kapa.ai•3mo ago

Hi @piffio. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave: ---------------------- Currently, Wasp does not support the direct use of Prisma enums in your code. This is a known limitation and there is an open issue on GitHub to track the progress of this feature (#641 (https://github.com/wasp-lang/wasp/issues/641)). As a workaround, a community member suggested creating a seeder function that uses $executeRawUnsafe to create the enum and upgrading to Prisma 5.10.2 as the version shipped with Wasp crashes Prisma Studio if an enum is defined in the database. However, this is a workaround and not an official solution. The Wasp team has plans to add support for all Prisma features, including enums, in the future. So, for now, you might have to wait for this feature to be implemented or use the suggested workaround. For more information, you can follow the discussion on this topic in the Wasp Discord server here (https://discord.com/channels/686873244791210014/1097604882011267102). ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @piffio, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

Sergio VisinoniOP•3mo ago

MEE6•3mo ago

Wohooo @piffio, you just became a Waspeteer level 1!

Sergio VisinoniOP•3mo ago

@kapa.ai any chance now?

kapa.ai•3mo ago

Let me check the knowledge base for you. One moment! :books: ---------------------- As of the latest information available in the provided sources, the support for Prisma enums in Wasp is still not implemented. The Wasp team has plans to add this feature, but it's not there yet. You can track the progress of this feature on the open GitHub issue #641 (https://github.com/wasp-lang/wasp/issues/641). For any recent updates not covered in the provided sources, I recommend checking the Wasp GitHub repository or their Discord server. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @piffio, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

Sergio VisinoniOP•3mo ago

@kapa.ai enums seem to be supported since this https://github.com/wasp-lang/wasp/pull/2035

GitHub

Using Prisma file alongside Wasp by infomiho · Pull Request #2035 ·...

This is some highly experimental work to move entities outside of the Wasp file and to put them in a regular schema.prisma file. In this PR we: extend the model parser to parse lists of Prisma mod...

kapa.ai•3mo ago

Let me check the knowledge base for you. One moment! :books: ---------------------- I'm sorry for any confusion, but the information provided in the knowledge sources does not include the pull request #2035 (https://github.com/wasp-lang/wasp/pull/2035) you mentioned. Therefore, I can't provide any specific details about it. However, if this pull request is indeed about adding support for Prisma enums in Wasp, then it's likely that the feature you're asking about has been implemented. To confirm this, I recommend checking the official Wasp documentation or reaching out to the Wasp community for the most accurate and up-to-date information. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @piffio, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

miho•3mo ago

You can import enums directly from @prisma/client. Keep in mind that Prisma will not export enums as types if you don't use them: https://github.com/prisma/prisma/issues/13382

GitHub

Client should contain Enum even if not used by a model · Issue #1...

Bug description Enum declared in the prisma.schema, but not used for any model field, is created in the migration but not in the client index.d.ts. I want to use the prisma.schema as the source of ...

Sergio VisinoniOP•3mo ago

Thanks @miho , I'll try importing directly from '@prisma/client' then! That worked, thanks a lot!

Sergio VisinoniOP•2mo ago

@miho I'm facing a follow-up issue with this, and I don't know if it's a wasp bug since it only manifests itself when I deploy the software in a live environment. Basically, I've been using Enums in my code following the approach you suggested, and all works well. But now my client once deployed doesn't load and fails with the following JS error

 Uncaught TypeError: Failed to resolve module specifier ".prisma/client/index-browser". Relative references must start with either "/", "./", or "../".

 Uncaught TypeError: Failed to resolve module specifier ".prisma/client/index-browser". Relative references must start with either "/", "./", or "../".

I've been looking online and tried following the suggestions found here https://github.com/sveltejs/kit/issues/4444 to use an alias in vite.config.ts, but it turns out prisma is not even installed as a dependency for the client, which kind of makes sense. Does this mean I'm stuck with not being able to use enums models in the client code or is there a better way to work around the issue with Wasp? @kapa.ai any idea?

GitHub

Error resolving module specifier “.prisma/client/index-browser”. · ...

Describe the bug I have the following error message in my browser upon using sveltekit (adaptor-node) and the command "npm run preview": Uncaught TypeError: Error resolving module specifi...

kapa.ai•2mo ago

Let me check the knowledge base for you. One moment! :books: ---------------------- I'm sorry, but your question is not clear. Could you please provide more details or context? I'm here to help with questions related to Wasp, a Rails-like framework for React, Node.js, and Prisma. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Sergio Visinoni, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

Sergio VisinoniOP•2mo ago

@kapa.ai see the previous conversation. I found a workaround that seems to work locally, but that includes manually installing prisma in the web-app directory prior to running the client, and I'm not sure that's the ideal approach. Furthermore, it requires me to stop using wasp deploy fly deploy as I'll need to fiddle with the content of the build directory before building the Docker container to be shipped on fly.

kapa.ai•2mo ago

Let me check the knowledge base for you. One moment! :books: ---------------------- Based on the information provided in the knowledge sources, it seems like you're trying to work around a limitation in Wasp's current support for Prisma enums. While your workaround might work locally, it's understandable that you're looking for a more streamlined solution for deployment. As for the deployment issue, you can use the --build-locally option with wasp deploy fly deploy to build your Docker container locally before deploying it to Fly.io. This would allow you to make necessary changes to the build directory before building the Docker container. Here's how you can do it:

wasp deploy fly deploy --build-locally

wasp deploy fly deploy --build-locally

This command will build the Docker container locally instead of using a remote Fly.io builder (source (https://wasp-lang.dev/docs/advanced/deployment/cli#building-locally)). However, please note that manually installing Prisma in the web-app directory and modifying the build directory might not be the best practice and could lead to unexpected issues. It's recommended to follow the official Wasp deployment process as closely as possible. As for the Prisma enums issue, the Wasp team is aware of this limitation and plans to add support for it in the future. You can track the progress of this feature on the open GitHub issue #641 (https://github.com/wasp-lang/wasp/issues/641). If you have further questions or run into any issues, I recommend reaching out to the Wasp community on their Discord server or GitHub repository for more specific guidance. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Sergio Visinoni, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

Sergio VisinoniOP•2mo ago

@kapa.ai do you know if it's on purpose that prisma models are not available to the client?

kapa.ai•2mo ago

Let me check the knowledge base for you. One moment! :books: ---------------------- Yes, it is intentional that Prisma models are not directly available to the client. This is due to the architecture of Wasp and the separation of concerns between the server and the client. In a typical Wasp application, the server side is responsible for interacting with the database using Prisma. The server exposes data to the client through queries and actions, which are defined in Wasp and implemented with JavaScript/TypeScript. The client side then consumes these queries and actions to interact with the data. This separation ensures that sensitive data and operations (like direct database access) are securely confined to the server side, while the client side only has access to the data it needs through a controlled interface (queries and actions). However, there is an open issue on GitHub (#901 (https://github.com/wasp-lang/wasp/issues/901)) discussing the possibility of exposing Prisma types as Wasp imports, which would make entity types Prisma generates available to users on both the server and the client. This would allow for better type safety and autocompletion in the client code. But it's important to note that this would only expose the types, not the actual Prisma models or the ability to perform direct database operations from the client. For more information, you can follow the discussion on this topic in the Wasp GitHub repository. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Sergio Visinoni, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

miho•2mo ago

Could you share a bit of code where you hit this issue so I reproduce it and play around with it? 🙂 I'd expect it to be possible to use the enum values from Prisma on the client as well - but I might be mistaken!

Sergio VisinoniOP•2mo ago

Sure @miho . Keep in mind I have a backend background and only started playing with React a couple of weeks ago when I discovered Wasp (loving it). I'm pretty sure I'm doing something wrong, though I was surprised to discover the issue only when I deployed, as in my local environment, everything is working as expected. One of those cases of works on my laptop I guess. So, I have defined this enum in Prisma:

enum OneToOneMeetingStatus {
  SCHEDULED
  COMPLETED
  POSTPONED
  CANCELLED
}

enum OneToOneMeetingStatus {
  SCHEDULED
  COMPLETED
  POSTPONED
  CANCELLED
}

I then import it my TS code like this import { OneToOneMeetingStatus } from '@prisma/client'; Then, I use the Models this way:

const getStatusColor = (status: OneToOneMeetingStatus) => {
        switch (status) {
            case 'SCHEDULED':
                return 'bg-blue-200 text-blue-800 dark:bg-blue-700 dark:text-blue-100';
            case 'COMPLETED':
                return 'bg-green-200 text-green-800 dark:bg-green-700 dark:text-green-100';
            case 'CANCELLED':
                return 'bg-red-200 text-red-800 dark:bg-red-700 dark:text-red-100';
            default:
                return 'bg-gray-200 text-gray-800 dark:bg-gray-600 dark:text-gray-100';
        }
    };

    const formatStatus = (status: OneToOneMeetingStatus | OneToOneMeetingOverallFeeling) => {
        return status.charAt(0).toUpperCase() + status.slice(1).toLowerCase();
    };

const getStatusColor = (status: OneToOneMeetingStatus) => {
        switch (status) {
            case 'SCHEDULED':
                return 'bg-blue-200 text-blue-800 dark:bg-blue-700 dark:text-blue-100';
            case 'COMPLETED':
                return 'bg-green-200 text-green-800 dark:bg-green-700 dark:text-green-100';
            case 'CANCELLED':
                return 'bg-red-200 text-red-800 dark:bg-red-700 dark:text-red-100';
            default:
                return 'bg-gray-200 text-gray-800 dark:bg-gray-600 dark:text-gray-100';
        }
    };

    const formatStatus = (status: OneToOneMeetingStatus | OneToOneMeetingOverallFeeling) => {
        return status.charAt(0).toUpperCase() + status.slice(1).toLowerCase();
    };

And here I'm blocked. If there is no easy way, I might use strings instead of enums for now, but then I'll introduce the risk of using invalid values by mistake. Thanks in advance! Another way could be to only import enums as types, rather than values, but then I'll have to again re-define all the possible values in the code @miho I can confirm that it works properly if I just import the type, and then re-declare the enum values in the code. Not the most elegant solution, but it works for now. At least I'm not blocked any longer. Still, I'd be curious to know if there is a way to properly reference enum values on the client side

miho•2mo ago

In short, I think you can't use enums as values on the client. We have this concept of "full-stack type safety" in Wasp which means you get things typed once on the server and you get access to those same types on the client. This works well because we can use a "trick" - we can import server types on the client because when the client is built, the types and type imports are striped away. You get the type support in your IDE + type checking but the types disappear when the client is built. Using enums as values breaks this "trick" - if you are importing values on the client - the import can't be striped away from the client and therefore it stays in the production build. The trouble there is that the Prisma Client and its code is a server-side thing which doesn't make it to the client bundle (nor it should get there because Node.js and the browser are different runtimes). I hope this makes sense to you and you are okay with your workaround based only on types 🙂 we'll investigate if we can further expand the trick we used to support also enums values alongside enum types 😄 cc: @sodic you'll find this interesting

Sergio VisinoniOP•2mo ago

Absolutely @miho , conceptually it makes perfect sense to no include prisma into the frontend, it's just that enums are a bit of a special case in the sense that the boundaries between what's a type and what's a model is a bit more blurred. I'm happy with the current workaround, thanks for taking your time

VS•2mo ago

+1 got this problem after I deployed, maybe this should check in wasp before deployment?

miho•2mo ago

maybe this should check in wasp before deployment

Could you elaborate, I didn't quite catch this 🙂

VS•2mo ago

Sorry! The code complies and runs on a local instance, maybe a small check that there is no enums on the schema.prisma could be good! Or a small sanity check to the wasp vscode extension. Thanks for making wasp! It's so impressive!

miho•2mo ago

Good idea 👍 checking if somebody used something from the server on the client.

martinsos•2mo ago

@miho anything here that might be worth capturin gin our github issues or do you think we already cover it all?

miho•2mo ago

Connected to this issue: https://github.com/wasp-lang/wasp/issues/2067#issuecomment-2426340243

GitHub

Detect server imports on the client · Issue #2067 · wasp-lang/wasp

Users sometimes import server specific code from wasp/server/* on the client and it's hard to debug. It's not obvious to new users that this is not something they shouldn't do since the...

Gaming

Programming

Referencing entities via enums