Use standalone Bun to build JS projects instead of NodeJS #20243
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does the pull request do?
Currently, both Avalonia.Browser and Avalonia.DesignerSupport assume node.js and npm are preinstalled on the current machine. It comes as an unexpected dependency, that we can't enforce.
Just as an experiment, I tried to use Bun packaged as a .NET 10 tool and see how well it works.
How was the solution implemented (if it's not obvious)?
Bun is a lightweight and performant JS runtime, popular as a replacement for node.js.
Since it's just 20-30mb per each platform, I was able to pack it as a .NET 10 native tool and upload to nuget - Bun.Unofficial.Tool (with RID specific packages win-x64, linux-x64, osx-arm64, osx-x64).
Said tool is then used with
dnx ToolName argumentscommand syntax, new .NET 10 mechanism to run tool without explicitly installing it globally (it's still downloaded in nuget cache and reused). See Running one-off .NET tools with dnx for more details.IMO, this approach is much easier to maintain than local .NET tools Microsoft recommended before.
Biggest part of git diffs is replacement of package.lock.json with bun.lock files. Technically, lock files are optional, but we used them before - so I kept new lock files in place too.
Additionally,
Avalonia.DesignerSupportis not anymore built by Nuke script, but instead by MSBuild target. Same withAvalonia.DesignerSupport.Tests(although, these are still executed by nuke)Breaking changes
None. List of dependencies is exactly the same, no JS package versions were updated. TS code is compiled and bundled with the same compiler, just different runtime to run JS tooling.
Fixed issues
Addresses one of the inconveniences in #19391