Package not adapted for monorepos with index files

[mocki-toki]

What version of Prisma Dart is running?

5.1.1

What version of Prisma CLI is running?

5.20.0

What type of app are you using?

Dart Native (Server/CLI)

What database are you using?

PostgreSQL

What steps can reproduce the bug?

1. Create two feature packages and generate their own Prisma clients.
2. In each package, create a file that exports all the files of the package (index file).
3. Create another package and import both packages through their index files.

A similar example can be found in my repository where the issue occurred: https://github.com/mocki-toki/designersss/blob/ccb66d2607d6a90ae904178292139f77f0e0fdfe/packages/backend/packages/storage_backend/lib/infrastructure/managers/storage.dart#L39

What is the expected behavior?

Both Prisma clients can be used without any issues.

What do you see instead?

A conflict arises between the following entities: QueryMode, NestedStringFilter, StringFilter, NestedDateTimeFilter, DateTimeFilter, SortOrder, AffectedRowsOutput, StringFieldUpdateOperationsInput, DateTimeFieldUpdateOperationsInput, NestedIntFilter, NestedStringWithAggregatesFilter, StringWithAggregatesFilter, NestedDateTimeWithAggregatesFilter, DateTimeWithAggregatesFilter.

Additional information

I am using a monorepo and atomic features concept, and have isolated Prisma instances for different packages. For example, the storage package is responsible for file storage functionality, and its schema.prisma file contains models for storing file metadata. Similarly, the account package has models in its schema.prisma for storing registered accounts and active sessions.

Now, I want to use both functionalities in the backend and need to import both packages. However, I encounter conflicts between the entities for filters and other parameters. These entities are generated in the prisma.dart file and are identical to each other. I believe they should be moved to an orm package to avoid conflicts in similar cases like mine.
Additionally, I don't like that I have to duplicate the .env file everywhere the Prisma client is generated. Also, identical binary files are generated in each package.

[medz]

OK, thanks for your feedback. I will create a minimal example and reproduce the bug. Please be patient.

[medz]

@mocki-toki I have completed the test, and I know your problem.

Let me give you an example. You have two files, a.dart and b.dart, both of which export class Test.

Then you import a.dart and b.dart at the same time in c.dart, so there is a conflict.

In addition, the Filter cannot be provided from the runtime, it can only be generated, because the content of the Filter field is different for each database and different field types (even if you may look similar.)

Solution:

Please use the as instruction to set an alias for the import.

For example, if you generate two clients a and b, they will both generate a StringFilter class, and client a can only use the StringFilter exported by a.

There is currently no good way to make two Filters compatible because they are both declared by Class. It may be solved in the future, such as using extension type to build Filter (but there may still be conflicts)

Solution 2:

Define the StringFilter base class in the runtime, all constraints require this base class, and then the generated client-related Filter inherits the base class to solve it.

All of the above require changes to the generator, and cannot be solved in a short time.

Currently, you can use import 'xxxx' as a; to set the prefix to solve it temporarily. This is because it is limited by the Dart language features.

[mocki-toki]

@medz Alright, thank you for the proposed solutions! I decided to simply move the Prisma instances into separate packages specifically designed for this purpose and dependent only on prisma-dart package. This way, it is easier for me to control the import, including working with prefixes.

However, I think it would be helpful to include an example of how to work with a monorepo-style package in the documentation, as the modular approach is quite popular for server development. For instance, the first time I implemented this approach, I encountered some issues. It wasn't immediately clear that for Prisma to work correctly, the binary file needed to be located in the endpoint package's folder.

[medz]

@medz Alright, thank you for the proposed solutions! I decided to simply move the Prisma instances into separate packages specifically designed for this purpose and dependent only on prisma-dart package. This way, it is easier for me to control the import, including working with prefixes.

However, I think it would be helpful to include an example of how to work with a monorepo-style package in the documentation, as the modular approach is quite popular for server development. For instance, the first time I implemented this approach, I encountered some issues. It wasn't immediately clear that for Prisma to work correctly, the binary file needed to be located in the endpoint package's folder.

Thank you for your suggestion. I will create an example about the secondary use case later, and this issue will be added to the optimization list of the next version.