Repository navigation
Conversation
A custom toolset URL was turned into a path by cutting off "file://". For "file:///C:/tools/nsis-bundle.zip", the form pathToFileURL gives on Windows, that leaves "/C:/tools/nsis-bundle.zip", which Windows never finds, so the toolset was rejected as invalid. Percent-encoded characters such as %20 were not decoded on any platform. Convert "file:///..." URLs with fileURLToPath. "file://<relative path>" and "file://C:\..." are not file URLs and keep the old handling. Co-Authored-By: Claude Opus 5.5 <[email protected]>
🦋 Changeset detectedLatest commit: b4f73c8 The changes in this PR will be included in the next version bump. This PR includes changesets to release 8 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Thanks, the
|
mmaietta
left a comment
mmaietta
left a comment
There was a problem hiding this comment.
Marking with request changes per previous comment.
On macOS and Linux, fileURLToPath reads "#" and "?" as the start of a fragment or a query, so "file:///opt/toolsets/electron-userland#3/nsis.zip" became the folder "/opt/toolsets/". That folder was returned as a directory toolset before the archive's checksum was read. A path with "?" or "#" in it now keeps the old handling. Add tests for the "#" and "?" case and the fileURLToPath fallback (macOS and Linux), and for a "file://C:\..." path being used as written (Windows). Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
Good catch, thanks! I went with your guard, so paths with |
A custom toolset
urllikefile:///C:/tools/nsis-bundle.zipdoesn't work on Windows.validateCustomToolsetandresolveFilePathturn the URL into a path by cutting offfile://, which leaves/C:/tools/nsis-bundle.zip. Windows never finds that path, so the build stops withInvalid custom toolset: file:///C:/... Must be a valid https:// URL or a file:// path.file:///C:/...is the formpathToFileURLgives on Windows, and the one thetoolsets.executablesdocs use (file:///C:/Windows/System32/...). Percent-encoded characters weren't decoded either, so a URL such asfile:///home/me/my%20tools/nsis.zipdoesn't work on any platform.The fix converts
file:///...URLs withfileURLToPath, likeexecutableUriToPathdoes fortoolsets.executables.file://<relative path>andfile://C:\...(what the existing tests use on Windows) aren't valid file URLs and keep the old handling.Test:
a file:// URL made with pathToFileURL resolves to the directory pathintest/src/customToolsetTest.tsuses a directory with a space in its name, so it also covers the decoding on Linux and macOS. It fails without the change (Invalid custom toolset: file:///D:/.../my%20toolset) and passes with it.TEST_FILES="customToolsetTest,appImageToolsetTest,7zipToolsetTest,legacyConfigGuardTest" pnpm ci:test: 316 passed on Windows 11. oxlint (type-aware), oxfmt andtsc --build tsconfig.build.jsonpass. A changeset forapp-builder-lib(patch) is included.I used Claude Code to write this change.