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

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

Open
katangafor opened this issue Oct 2, 2023 · 6 comments
Open

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

katangafor opened this issue Oct 2, 2023 · 6 comments

Comments

@katangafor
Copy link

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
Copy link
Collaborator

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
Copy link
Collaborator

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:

katangafor/parjs-vitest-error#1

@mikavilpas
Copy link
Collaborator

mikavilpas commented Feb 24, 2024

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 #39 . I'm not sure this is the cause though, so this really needs more looking into.

@wycats
Copy link

wycats commented Jun 1, 2024

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
Copy link
Contributor

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
Copy link

almibe commented Jul 30, 2024

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?

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

6 participants