Build and dependencies updates

[limzykenneth]

This updates various build and dependencies with major points listed below (these may change over time and will be updated, see edit history for previous versions):

• Migrate build from Rollup to Rolldown
• Upgrade Vite and Vitest to latest version
• Migrate from Webdriverio to Playwright in Vitest browser mode
• More to come...

Please do test out any latest build with the continuous release CDN link below and report any issues with build, test, or bugs.

[p5-bot]

Continuous Release

CDN link

• https://raw.esm.sh/pr/p5@451d743/lib/p5.min.js

Published Packages

• https://pkg.pr.new/p5@451d743

Commit hash: 451d743

Previous deployments

2f1eead

• https://raw.esm.sh/pr/p5@2f1eead/lib/p5.min.js
• https://pkg.pr.new/p5@2f1eead

ccdb43b

• https://raw.esm.sh/pr/p5@ccdb43b/lib/p5.min.js
• https://pkg.pr.new/p5@ccdb43b

4f666c3

• https://raw.esm.sh/pr/p5@4f666c3/lib/p5.min.js
• https://pkg.pr.new/p5@4f666c3

aea0da1

• https://raw.esm.sh/pr/p5@aea0da1/lib/p5.min.js
• https://pkg.pr.new/p5@aea0da1

aced934

• https://raw.esm.sh/pr/p5@aced934/lib/p5.min.js
• https://pkg.pr.new/p5@aced934

f6f6463

• https://raw.esm.sh/pr/p5@355d1e6/lib/p5.min.js
• https://pkg.pr.new/p5@355d1e6

---

This is an automated message.

[Vaivaswat2244]

vitest.config.js only applies the SwiftShader software-rendering Chromium flags when process.env.CI is set:

provider: playwright({
              capabilities: process.env.CI
                ? {
                    'goog:chromeOptions': {
                      args: [
                        '--no-sandbox',
                        '--headless=new',
                        '--enable-unsafe-webgpu',
                        '--use-vulkan=swiftshader',
                        '--use-webgpu-adapter=swiftshader',
                        '--use-angle=vulkan'
                      ]
                    }
                  }
                : undefined
            }),

So CI renders text through SwiftShader while a local run uses whatever hardware-accelerated backend is on the machine. The 3 failing baselines were captured on the hardware path and were never regenerated for SwiftShader. that's the mismatch, not anything about the Rolldown/Playwright migration itself.

Ruled out a couple of alternatives before landing on that: (context: pixelmatch algo )

• Not simple AA/line-shift noise — ran the diffs through the clustering algo already in visualTest.js: significantDiffPixels came out at 160 and 257 against the 40px threshold, way past what tolerance-tuning could reasonably absorb.
• Not font-hinting — added --font-render-hinting=none --disable-lcd-text on top of the CI flags and reran under CI=true: diff numbers came back byte-identical, no change at all.
• Not font substitution — all 3 failing tests load the same bundled test/unit/assets/Inconsolata-Bold.ttf via loadFont(), not an OS-resolved font like 'monospace'/'serif', so it's the same font bytes locally and in CI either way.

Plan:
Firstly, I guess we should drop the process.env.CI ternary so the SwiftShader args always apply, local and CI alike keeps future baselines reproducible for every contributor instead of tied to one machine's renderer. And then we have to regenerate just the 3 affected typography screenshots under that path.

The screenshots should be regenerated because in order to incorporate the build updates, we either have to update the thresholds in the matching algo checkMatch which might some flase negatives in tests, or we can regenrate baselines to match CI's standard everywhere (these are only 3 tests).

cc @davepagurek

[limzykenneth]

For the SwiftShader flag, I think it should either not be used or only be used in CI. Typical users don't run their browsers with that flag enabled and us testing with it enabled can potentially cause false positives, it is currently there guarded behind the CI flag because it's needed to run on the GitHub Actions image since there's no GPU attached to the images.

The screenshots of what's rendered vs what can be seen locally is a bit concerning as well though.

[Vaivaswat2244]

After some more digging, and some more runs using CI = true I think this has nothing to do with SwiftShader. Playwright is using chromium which drives its own Chromium, This browser difference in baselines and these images are causing the failures. This is a headless vs headed browser problem. Making browser and channel as chrome, all the tests are passing.

[Vaivaswat2244]

adding channel: chrome and browser : chrome should fix this

provider: playwright({
              launchOptions: process.env.CI
                ? { 
                    channel: 'chrome',
                    args: [
                      '--headless=new',
                      '--no-sandbox',
                      '--enable-webgl',
                      '--use-gl=angle',
                      '--use-angle=swiftshader-webgl',
                      '--enable-unsafe-swiftshader'
                    ]
                  }
                : { channel: 'chrome' }
            })

[limzykenneth]

Seems to have cleared it now. It won't be possible to use browser: 'chrome' as that is not a supported browser and it requires contributors to have Chrome installed which not everyone may want to. Using channel: 'chromium' seems to be the recommendation from Playwright and Google Chrome team regarding something closest to real Chrome in a headless environment.

[limzykenneth]

@davepagurek Almost every part once migrated over to zimmerframe seems to be working except this part which causes some kind of NaN problem. Can you have a look when you are able? I'm not super familiar with how to debug strands and shaders.

[Vaivaswat2244]

@limzykenneth — since this swaps WebdriverIO for Playwright, it also clears the blocker that closed #8853: the Node 24 runner pulled Chrome 148 and WebdriverIO couldn't fetch a matching driver. Playwright manages its own browser, so that failure mode goes away. Should close #8674 as well

[limzykenneth]

@Vaivaswat2244 Yes, that's part of the reason why we are switching to playwright amongst other things.

[ulgens]

Hey, asking to learn, where can I find the relates issue for these changes? The PR is huge and making multiple tooling changes, which I believe they were previously discussed and decided but there is no references in the PR description.

[ulgens]

Also, is there anything I can help to push this forwards? The PR looks a bit too big, and even when it's merged - it will make navigating in the history harder than it can be. Considering it also blocks several security-related fixes/updates, I'll recommending breaking this PR into smaller pieces - which I can help with.

[limzykenneth]

@ulgens This is part of the maintenance and devops upgrade for the repo, including tooling changes. They are discussed as part of repo maintenance with core maintainers including dependencies updates and changes. Part of it is the switch of linting and formatting from eslint to oxlint/oxfmt, this change is where the largest part of the PR comes from since it is automated formatting changes. The formatting changes are also contained within a single commit, meaning other more meaningful changes are in their own commit so navigation shouldn't be an issue, especially with a bisect workflow.

I'm not looking to break this into smaller pieces, especially where the devops could have mutual relationship, breaking into smaller pieces mean we need stop gap solution between merging each switch.

To move this forward, the zimmerframe issue with p5.strands needs to be resolved, if you'd like, do have a look into that.

[ulgens]

@limzykenneth Thanks for the details.

They are discussed as part of repo maintenance with core maintainers including dependencies updates and changes.

Does this mean those discussions are not publicly accessible? I was curious about the tooling selection, and what were the alternatives but couldn't find any conversation/documentation on the reasoning.

The formatting changes are also contained within a single commit, meaning other more meaningful changes are in their own commit so navigation shouldn't be an issue, especially with a bisect workflow.

I'm more worried about the "merge 'main' into" commit and a non-linear merge. These two almost always creates issues in history, sometimes causing a 3-way duplicate commits.

Also, coming from #9032 (comment), it seems we are already having worries about this PRs content. In my experience, if something is hard or risky to rebase, it mean it's already too big and late for a merge.

breaking into smaller pieces mean we need stop gap solution between merging each switch.

I completely missed this one. The PR includes multiple type of contributions / updates, which some of them can be extracted in a perfectly clean way. Cleaning of trailing white spaces can be merged separately from

the zimmerframe issue with p5.strands needs to be resolved

without any need for a stop gap solution. I think that having a p5.strands related bug as a blocker for dependency updates in CI is an issue that can be fixed pretty easily by splitting the work.

All being said, my intention is just to help and remove blockers, so I support whatever approach is the fastest one.

[limzykenneth]

@ulgens If the tooling choice and commit history here doesn't work, it is fine to start over and have another PR or several. This PR is intentionally set as draft because it is work in progress, it is much easier to share work in progress in a PR with a CR link than doing this over other channels. The CI problems are also often only present in the CI environment so that's also why a PR is useful.

It would be good to have some feedback on the specific changes in the PR though, the larger theme is to update the dependencies, both in terms of versions and what we actually use, aiming to modernize the dependencies and reduce bundle size.

[limzykenneth]

There may not be enough capacity to tackle zimmerframe and related changes in this PR, let's just go with the build updates only in #9062 so that we can unlock other things that are in the works.