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

bun install fails for complex dependency version #715

Closed
2 tasks done
RobinKnipe opened this issue Mar 19, 2024 · 4 comments
Closed
2 tasks done

bun install fails for complex dependency version #715

RobinKnipe opened this issue Mar 19, 2024 · 4 comments

Comments

@RobinKnipe
Copy link

Before You File a Bug Report Please Confirm You Have Done The Following...

  • I have tried restarting my IDE and the issue persists.
  • I have updated to the latest version of the packages.

What version of ESLint are you using?

8.57.0

What version of eslint-plugin-svelte are you using?

2.36.0-next.12

What did you do?

bun create svelte@latest
# choose eslint, prettier, svelte5
bun install

What did you expect to happen?

Dependencies install successfully

What actually happened?

bun fails to process the composite version syntax ">=0.34.0-next.12 <1.0.0" and errors without adding any modules!

$ bun install
bun install v1.0.26 (c75e768a)
warn: incorrect peer dependency "svelte@5.0.0-next.80"

error: No version matching ">=0.34.0-next.12 <1.0.0" found for specifier "svelte-eslint-parser" (but package exists)

Link to GitHub Repo with Minimal Reproducible Example

https://github.com/RobinKnipe/eslint-plugin-svelte-issue

Additional comments

PR for suggested fix: #714

@ota-meshi
Copy link
Member

I think it's a bug in bun. I think that version specification needs to be valid.

@ota-meshi ota-meshi closed this as not planned Won't fix, can't repro, duplicate, stale Mar 19, 2024
@RobinKnipe
Copy link
Author

I think it's a bug in bun. I think that version specification needs to be valid.

It is a shortcoming of the bun version support, sure. But given the problem can be fixed by merely simplifying the version number, why not do that? The 2 versions are semantically the same, so as a general rule try to use the more brutally supported style, no?

@ota-meshi
Copy link
Member

They are not actually the same. I use that syntax intentionally.

@RobinKnipe
Copy link
Author

Ok, I'll continue to use the fork until the situation improves. Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants