Open katangafor opened 1 year ago
Thanks for the reproduction repo. I'll try to make some time to take a look at this issue in the coming days. Have been meaning to take a look at vitest anyway, so this is a great excuse.
I also love the link to nom
. I did some advent of code problems with Rust and tried out https://pest.rs/ just for fun. I think I need to try nom
whenever I write some more rust.
I could reproduce the issue locally on osx with node 20.9.0.
I could not resolve it, and was not able to find out why this might have happened.
However, I was able to get the tests running in vitest -> chrome using these changes:
I'm not familiar with vitest, so it's a bit difficult to say what the cause of this could be.
I suppose it may have something to do with https://github.com/GregRos/parjs/issues/39 . I'm not sure this is the cause though, so this really needs more looking into.
I believe I worked out what the issue is. In the current published package, each export has an entry for require
, importand
default, but they all point to the same
.jsfile, which uses
module.exports` (i.e. CJS semantics).
I was able to get my tests to run by modifying my imports to:
import { createRequire } from "node:module";
const require = createRequire(import.meta.url);
const { regexp, string } = require("parjs");
const { manyTill, or } = require("parjs/combinators");
This is not a good solution, because it causes TS to assign any
to all of the types and won't work with other ESM tools. But it suggests that the problem would be solved by publishing a version of parjs
with ESM modules.
I can get type completion by writing it this way. This is also not a good solution, but I hope it helps someone.
import { createRequire } from "node:module";
const require = createRequire(import.meta.url);
const { regexp, string } = require("parjs") as typeof import("parjs");
const { manyTill, or } = require("parjs/combinators") as typeof import("parjs/combinators");
Just ran into this. I was actually testing the library out using vitest and was confused why a project that had such good documentation had zero working code examples since everything just hung. Maybe a note about this could be added to the README or other docs until a better fix is in place?
First of all, LOVE the library! This is the only combinator library in TS that scratches the nom itch.
Normally I wouldn't put this straight into "issues"; I'd post it in the discussion section, since this is definitely a vitest issue and not a parjs issue. But I thought y'all might have more insight into this than me.
When running the example from the readme, it seems like any line that includes .pipe() causes a vitest test to run forever.
Here's a repo showing off the weirdness.
I have very few guesses as to what the problem could be, but I'm pretty sure it's nothing to do with TS compilation because the same problem happens when I change the test file to be JS.