GregRos / parjs

JavaScript parser-combinator library
MIT License
273 stars 18 forks source link

.pipe() function causes vitest to hang infinitely #59

Open katangafor opened 1 year ago

katangafor commented 1 year ago

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.

barona-mika-vilpas commented 11 months 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.

mikavilpas commented 8 months ago

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:

https://github.com/katangafor/parjs-vitest-error/pull/1

mikavilpas commented 8 months ago

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.

wycats commented 5 months ago

I believe I worked out what the issue is. In the current published package, each export has an entry for require, importanddefault, but they all point to the same.jsfile, which usesmodule.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.

koyashiro commented 4 months ago

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");
almibe commented 3 months ago

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?