Inconsistent pattern evaluation between build and watch modes

[reebalazs]

Describe the bug

Build mode silently fails. with or without --build: same result.

It writes Using a pool of 8 threads., but no file is generated. It neither gives an error.

Watch mode with the same config works correctly.

I am running the script from the CLI, node 22, OSX darwin

EDIT I used the following test match pattern (which caused the problem, see conversation):

  "srcDir": "./(src|__tests__)/**/*"

Expected behavior

It should work without watch mode, with or without --build, and compile the files with a single run.

Test case

Please confirm this manually, if you can reproduce, I'm glad to spend more time to provide the test case. To me this is happening consistently with the newest version, but I have not noticed because I am checking in the compilation results to git and using watch mode.

If you cannot reproduce then I will work on figuring out why it happens in my environment.

[reebalazs]

BUMP

Can someone at least try to reproduce this? This is so annoying that I start thinking that maybe the problem is only on my side. But if so, I'd like to find it out.

The idea that build without watch is broken in general, is kind of serious.

@zth would you please take a look and comment?

[zth]

@reebalazs sorry, for some reason I do not get notifications for this repo. I have not seen that issue IIRC, but given I check in the generated files maybe I need to check one extra time. I'll get back to you.

[zth]

@reebalazs seems to work on the projects I've tried it on. Do you get no output at all in the terminal?

[reebalazs]

@zth thanks for checking it!

I get the output, it looks like success, but it's not actually writing the files.

%  yarn pgtyped-rescript --build -c pgtyped.config.json
Using a pool of 8 threads.

I'm back soon with a standalone test to make it easier to reproduce.

[reebalazs]

@zth ah ok, I've figured this out.

My test file pattern was broken, so actually no file was parsed.

  "srcDir": "./(src|__tests__)/**/*"

This is wrong on multiple accounts...

• {src|__tests__} is invalid as a glob pattern, {src,_tests__} is correct.
• The wildcards in the end are not needed and are just make the scanning more complex without a reason.

The correct pattern in my case:

  "srcDir": "./{src,__tests__}"

Now the next question, why did this only fail in build, but work in watch mode? - Both modes use the same pattern, but different libraries:

• Build mode: Uses globSync(pattern) from the glob package (index.ts line 119)
• Watch mode: Uses chokidar.watch(pattern) (index.ts line 110-113)

Chokidar (which uses picomatch internally) interprets (src|__tests__) as an extglob pattern meaning "src OR tests", so it successfully matches files.

Glob treats (src|__tests__) as a literal string and looks for a directory literally named (src|__tests__) — which doesn't exist, so it finds 0 files.

So there is an inconsistency here - for what it's worth, I've generated some tests and a solution to use chokidar in both cases, happy to submit it as a PR, but I'm curious about your opinion: would using chokidar instead of globbing in the build case be the proper solution? Or is there some other solution that you would prefer? (Either way I'm happy because my current problem is solved.)

Reference: reebalazs#1

[zth]

Interesting, thanks for figuring it out! Please do submit a PR, although it's likely it'll be a little while before I get back to working on this package.

Part of the reason is that I'm actually planning on deprecating this package in favor of a ReScript "adapter" for https://github.com/wsporto/typesql. I've got 90% of the code generation done, just a matter of tying it all together with embed lang etc (until embed lang ships as a native feature of ReScript).

Some of the benefits of moving to typesql are:

• Better/more precise typegen. Can handle nullability better, JSON shapes, and more
• pgtyped is largely abandoned and with no clear foundation for more advanced analysis/typegen. Typesql is maintained and has a full foundation for advanced analysis (hence why it can build JSON shapes in types etc)
• Support for SQLite and MySQL. Especially SQLite is really interesting

Is this something you'd be interested in as well?

[reebalazs]

That's great to hear! I suspected pgtyped might be abandoned and was going to ask what you've moved to.

In my experience, type generation for SQL queries is critical. Without it, you introduce a weak link into an otherwise strongly typed system. The more you can catch at compile time, the better. With pgtyped, I found that about 90% of issues surfaced during compilation, with only a few runtime edge cases slipping through. I'm curious how the typesql-based approach holds up in comparison.

While a part of the industry is shifting toward higher abstractions like GraphQL, plain SQL still has real advantages. First-class support for this in ReScript would be a significant win, in my opinion.

My main interest is Postgres, though I do encounter MySQL from time to time. I agree that SQLite is an intriguing option too: it opens up some exciting possibilities, like embedding a database directly into an app.

I'd appreciate the link and any notes on the current state. I'll definitely check it out.