Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot work with pnpm #925

Closed
ImSingee opened this issue Feb 6, 2024 · 6 comments
Closed

Cannot work with pnpm #925

ImSingee opened this issue Feb 6, 2024 · 6 comments

Comments

@ImSingee
Copy link

ImSingee commented Feb 6, 2024

After upgrading to 0.9.2, can't use with pnpm any more.

Reproduce:

npx create-electric-app@latest test
cd test
# change version of electric-sql to 0.9.2
pnpm install
pnpm add zod
pnpm backend:start
pnpm db:migrate
pnpm client:generate
pnpm build

Error:

image


> [email protected] build /private/tmp/test2/test
> tsc && vite build

src/generated/client/index.ts:3:38 - error TS6133: 'Relation' is declared but its value is never read.

3 import { type TableSchema, DbSchema, Relation, ElectricClient, type HKT } from 'electric-sql/client/model';
                                       ~~~~~~~~

src/generated/client/index.ts:63:14 - error TS2322: Type 'ZodObject<{ value: ZodOptional<ZodString>; }, "strict", ZodTypeAny, { value?: string | undefined; }, { value?: string | undefined; }>' is not assignable to type 'ZodType<ItemsWhereUniqueInput, ZodTypeDef, ItemsWhereUniqueInput>'.
  Types of property '_type' are incompatible.
    Type '{ value?: string | undefined; }' is not assignable to type 'ItemsWhereUniqueInput'.
      Type '{ value?: string | undefined; }' is not assignable to type '{ value: string; } & { value?: string | undefined; AND?: ItemsWhereInput | ItemsWhereInput[] | undefined; OR?: ItemsWhereInput[] | undefined; NOT?: ItemsWhereInput | ... 1 more ... | undefined; }'.
        Type '{ value?: string | undefined; }' is not assignable to type '{ value: string; }'.
          Types of property 'value' are incompatible.
            Type 'string | undefined' is not assignable to type 'string'.
              Type 'undefined' is not assignable to type 'string'.

63 export const ItemsWhereUniqueInputSchema: z.ZodType<Prisma.ItemsWhereUniqueInput> = z.object({
                ~~~~~~~~~~~~~~~~~~~~~~~~~~~


Found 2 errors in the same file, starting at: src/generated/client/index.ts:3
Copy link

linear bot commented Feb 6, 2024

@kevin-dp
Copy link
Contributor

kevin-dp commented Feb 6, 2024

The first issue occurs because our generator does not remove the import for Relation if it is not used by the actual schemas. You can fix the issue by removing the import for Relation while waiting for us to fix the generator accordingly. I'm not exactly sure why the second issue occurs. Hard to tell without knowing your DB schema. If you can provide your DB schema we can try to reproduce these errors. In any case, these are type errors in the generated client, you can unblock yourself for now by adding a // ts-ignore above line 63.

@ImSingee
Copy link
Author

ImSingee commented Feb 6, 2024

@kevin-dp The DB is very simple

/* This is an example of an SQL DDL migration. It creates an `items` table and
 * then calls an `electric.electrify` procedure to expose the table to the
 * ElectricSQL replication machinery.
 *
 * Note that these statements are applied directly to the *Postgres* database.
 * Electric then handles keeping the local SQLite database schema in sync with
 * the electrified subset of your Postgres database schema.
 *
 * See https://electric-sql.com/docs/usage/data-modelling for more information.
 */

-- Create a simple items table.
CREATE TABLE IF NOT EXISTS items (
  value TEXT PRIMARY KEY NOT NULL
);

-- ⚡
-- Electrify the items table
ALTER TABLE items ENABLE ELECTRIC;

(It's just created by create-electric-app)

Copy link
Contributor

balegas commented Feb 7, 2024

This doesn’t seem to have any particular issue. It should just work. @kevin please try to run commands from 0.9.2

@fooware
Copy link
Contributor

fooware commented Feb 28, 2024

The second issue looks like the same problem as in issue #1001, and thus potentially solved by PR #1016.

@msfstef
Copy link
Contributor

msfstef commented Apr 1, 2024

Closing this in favour of keeping #1001 open as they refer to the same issue.

Make sure that your tsconfig.json compiler options has strict set to true (and strictNullChecks not set to false as it invalidates some of the "strictness" required by Zod, the schema validator).

The Related unused import will be fixed by #1117.

@msfstef msfstef closed this as not planned Won't fix, can't repro, duplicate, stale Apr 1, 2024
msfstef added a commit that referenced this issue Apr 3, 2024
…ests (#1117)

Relevant issues: #1001
#925
#1114

Only one thing is fixed in this PR, the `Relation` is no longer imported
if the data model has no relations in order to avoid `unused imports` TS
errors.

Main changes are moving all of the generator tests into their own test
directory rather than inside the source code, for consistency with the
TS client, ease of use, and improved reusability of test utilities.

I've also added a sort of integration test for the CLI generation step,
which is crucial to getting a working, compileable TS client as it
modifies some of the Prisma generated typings. This test generates the
client given a Prisma schema and performs all appropriate modifications
to it, and then attempts to compile it with TS and specified compiler
options.

Also found that with TS version >=5.4 we have [stricter conditional type
checking](https://devblogs.microsoft.com/typescript/announcing-typescript-5-4/#notable-behavioral-changes)
which breaks clients generated with Prisma versions earlier than 4.16.0
(see issue #1114),
however 4.16.0 introduces breaking changes with the "extensions"
feature, so I've added a hacky workaround for it:

https://github.com/electric-sql/electric/pull/1117/files#diff-fb0a50df4fc86f09b81a210162984d7822276fe19c8ae6496cf5ffe7d09f5adb

We can add more tests that would test various compiler options, making
it easier to avoid regressions when users report them with more
complicated schemas and TS compiler options.

Finally, I've added a Caution banner in our Usage section in the docs
about requiring TS `strict` mode, since Zod has that as a requirement as
well and its the reason why we see some inconsistencies in bug reports.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants