-
-
Notifications
You must be signed in to change notification settings - Fork 117
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 support #290
Bun support #290
Conversation
At a glance this looks good, but we're gonna need a test to verify the functionality, I think adapting result1 and result2 from this test should get you most of the way |
Yeah, gonna add tests for sure. Also gonna add |
I'd skip the task rules, the personal experience I've got with them is that they're good for build engineers (who don't like them) and absolutely awful for average users (who loves them) |
Alright, I think this should be somewhat complete. I would expect that some GH actions could fail on different OSes - if that happens I'm gonna try fix it asap. Let me know if there's anything else to be done :) |
Also all the |
Conditional tasks gets a little weird when you want to depend on them, and from experience it seems most people use the install tasks anyways (mostly with ephemeral environments) I'm gonna have time to review this properly on Sunday or during next week, but at a glance it looks good, if it's merged I may change the API. |
I have a hard time imaging how it could work on Windows and how users could make bun tasks work. So for now if a project uses any of bun related stuff gradle builds will just fail. The only thing I can think of is providing "temporary" Windows support via WSL2. But it would have a few quirks:
My suggestion would be to make it as simple as possible: if before-mentioned feature flag is turned on then we will assume that user has WSL installed as well as bun (on the WSL). So Let me know what you think about it, I could do a follow up PR with such "experimental" support. PS I'm a Windows user so it's feasible to develop it on my end, but I don't know how it will look in terms of testing on CI |
We'll skip initial Windows support, WSL support might be useful on its own (in general for the plugin), but is a major change (code-wise) and can wait :-) |
From an initial glance this looks good, I'm looking into the test failures and some of them are caused by tests that assume local binaries being available (which is ok, I'll fix that on CI later) |
Okay there's some little-bit-more-than-slight cleanup that needs to be done as well, I'll work on that after merging but I'm gonna list the things here before extracting them to a new issue
|
Most of that is because the general test setup in gradle-node-plugin is unwieldy :-) |
Hi, I was thinking about developing a standalone bun gradle plugin, but stumbled upon this issue (#288) and thought that I can give it a try.
For now, it's WIP but I tested it out and installing bun and running it somewhat works. Still, there probably will be a lot more stuff to be done. If you have any suggestion/pointers I will gladly take any advice - at this state it's basically a copy of pnpm/yarn setup.
And there is one major issue: bun is not yet supported on windows :( Normally I would work around it by using WSL but I'm not sure how's that gonna play with the rest of the code. So I guess windows support would be out of scope in this PR