fix: use absolute urls for published sourcemap urls

[rexxars]

Description

The source maps we upload to our module CDN now contains source maps, which helps in debugging. Sources are inlined, but the original source locations are also left intact. This isn't a problem per se, but it does lead to tooling trying to link to them and failing. For instance, a source map could be referencing ../../../node_modules/.pnpm/@[email protected][email protected]/node_modules/@sanity/client/dist/index.browser.js, which would be resolved to https://modules.sanity-cdn.com/modules/v1/node_modules/.pnpm/@[email protected][email protected]/node_modules/@sanity/client/dist/index.browser.js, which we obviously do not host.

It is helpful to have some source location, as from the example above I can see that the source pointed to @sanity/client. To make this even more helpful, this PR takes the approach of rewriting these sources to point to absolute URLs.

Technically speaking this is "incorrect", as we don't use the URLs given for actually building the bundles, however it is useful for debugging purposes, and leaving the original paths do not make sense as we are not hosting the source files on the CDN anyway.

The URLs we rewrite to are as follows:

• For absolute URLs, leave them as-is.
• For dependencies (eg anything inside of node_modules), we use jsdelivr.net.
• For Sanity monorepo packages, we use GitHub URLs. Note that these link to the HTML interface, NOT the raw file - so any tools that tries to actually fetch the file might fail. If this proves to be an issue, we could switch to raw.githubusercontent.com instead, but it is less user-friendly for us developers.

What to review

• Do these changes make sense? Are they going to cause issues?
• See any issues in the code?

Testing

I've built the bundles locally and ran a modified uploading script (disabling the actual upload logic) and verified that the sources gets correctly rewritten.

Notes for release

None

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
page-building-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 7, 2024 3:57pm
performance-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 7, 2024 3:57pm
test-compiled-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 7, 2024 3:57pm
test-next-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 7, 2024 3:57pm
test-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 7, 2024 3:57pm

1 Skipped Deployment

Name	Status	Preview	Comments	Updated (UTC)
studio-workshop	⬜️ Ignored (Inspect)	Visit Preview		Oct 7, 2024 3:57pm

[github-actions]

No changes to documentation

[socket-security]

New dependencies detected. Learn more about Socket for GitHub ↗︎

Package	New capabilities	Transitives	Size	Publisher

View full report↗︎

[github-actions]

Component Testing Report Updated Oct 7, 2024 3:54 PM (UTC)

✅ All Tests Passed -- expand for details

File	Status	Duration	Passed	Skipped	Failed
comments/CommentInput.spec.tsx	✅ Passed (Inspect)	45s	15	0	0
formBuilder/ArrayInput.spec.tsx	✅ Passed (Inspect)	9s	3	0	0
formBuilder/inputs/PortableText/Annotations.spec.tsx	✅ Passed (Inspect)	31s	6	0	0
formBuilder/inputs/PortableText/copyPaste/CopyPaste.spec.tsx	✅ Passed (Inspect)	39s	11	7	0
formBuilder/inputs/PortableText/copyPaste/CopyPasteFields.spec.tsx	✅ Passed (Inspect)	0s	0	12	0
formBuilder/inputs/PortableText/Decorators.spec.tsx	✅ Passed (Inspect)	18s	6	0	0
formBuilder/inputs/PortableText/DisableFocusAndUnset.spec.tsx	✅ Passed (Inspect)	10s	3	0	0
formBuilder/inputs/PortableText/DragAndDrop.spec.tsx	✅ Passed (Inspect)	3m 0s	0	0	0
formBuilder/inputs/PortableText/FocusTracking.spec.tsx	✅ Passed (Inspect)	45s	15	0	0
formBuilder/inputs/PortableText/Input.spec.tsx	✅ Passed (Inspect)	1m 40s	21	0	0
formBuilder/inputs/PortableText/ObjectBlock.spec.tsx	✅ Passed (Inspect)	1m 18s	18	0	0
formBuilder/inputs/PortableText/PresenceCursors.spec.tsx	✅ Passed (Inspect)	9s	3	9	0
formBuilder/inputs/PortableText/RangeDecoration.spec.tsx	✅ Passed (Inspect)	26s	9	0	0
formBuilder/inputs/PortableText/Styles.spec.tsx	✅ Passed (Inspect)	18s	6	0	0
formBuilder/inputs/PortableText/Toolbar.spec.tsx	✅ Passed (Inspect)	36s	12	0	0
formBuilder/tree-editing/TreeEditing.spec.tsx	✅ Passed (Inspect)	0s	0	3	0
formBuilder/tree-editing/TreeEditingNestedObjects.spec.tsx	✅ Passed (Inspect)	0s	0	3	0

[github-actions]

⚡️ Editor Performance Report

Updated Mon, 07 Oct 2024 16:05:08 GMT

Benchmark	reference latency of sanity@latest	experiment latency of this branch	Δ (%) latency difference
article (title)	18.3 efps (55ms)	18.9 efps (53ms)	-2ms (-2.8%)	✅
article (body)	59.5 efps (17ms)	63.3 efps (16ms)	-1ms (-6.0%)	✅
article (string inside object)	20.0 efps (50ms)	19.0 efps (53ms)	+3ms (+5.0%)	✅
article (string inside array)	15.6 efps (64ms)	15.0 efps (67ms)	+3ms (+3.9%)	✅
recipe (name)	30.3 efps (33ms)	31.3 efps (32ms)	-1ms (-3.0%)	✅
recipe (description)	34.5 efps (29ms)	34.5 efps (29ms)	+0ms (-/-%)	✅
recipe (instructions)	99.9+ efps (6ms)	99.9+ efps (6ms)	+0ms (-/-%)	✅
synthetic (title)	15.2 efps (66ms)	15.9 efps (63ms)	-3ms (-4.5%)	✅
synthetic (string inside object)	16.1 efps (62ms)	15.6 efps (64ms)	+2ms (+3.2%)	✅

efps — editor "frames per second". The number of updates assumed to be possible within a second.

Derived from input latency. efps = 1000 / input_latency

Detailed information

🏠 Reference result

The performance result of sanity@latest

Benchmark	latency	p75	p90	p99	blocking time	test duration
article (title)	55ms	62ms	94ms	218ms	1230ms	15.0s
article (body)	17ms	19ms	32ms	148ms	286ms	5.8s
article (string inside object)	50ms	54ms	63ms	168ms	906ms	8.6s
article (string inside array)	64ms	67ms	76ms	226ms	1596ms	9.6s
recipe (name)	33ms	36ms	40ms	69ms	36ms	9.6s
recipe (description)	29ms	30ms	34ms	53ms	23ms	6.1s
recipe (instructions)	6ms	8ms	9ms	28ms	0ms	3.3s
synthetic (title)	66ms	69ms	75ms	422ms	2034ms	17.2s
synthetic (string inside object)	62ms	66ms	74ms	371ms	1645ms	10.0s

🧪 Experiment result

The performance result of this branch

Benchmark	latency	p75	p90	p99	blocking time	test duration
article (title)	53ms	57ms	69ms	119ms	945ms	13.8s
article (body)	16ms	19ms	25ms	207ms	219ms	5.6s
article (string inside object)	53ms	56ms	74ms	114ms	804ms	8.4s
article (string inside array)	67ms	70ms	74ms	287ms	1607ms	9.9s
recipe (name)	32ms	36ms	59ms	76ms	69ms	9.3s
recipe (description)	29ms	31ms	35ms	62ms	48ms	6.2s
recipe (instructions)	6ms	9ms	10ms	12ms	0ms	3.3s
synthetic (title)	63ms	66ms	79ms	190ms	1942ms	15.3s
synthetic (string inside object)	64ms	67ms	82ms	446ms	2259ms	10.0s

📚 Glossary

column definitions

• benchmark — the name of the test, e.g. "article", followed by the label of the field being measured, e.g. "(title)".
• latency — the time between when a key was pressed and when it was rendered. derived from a set of samples. the median (p50) is shown to show the most common latency.
• p75 — the 75th percentile of the input latency in the test run. 75% of the sampled inputs in this benchmark were processed faster than this value. this provides insight into the upper range of typical performance.
• p90 — the 90th percentile of the input latency in the test run. 90% of the sampled inputs were faster than this. this metric helps identify slower interactions that occurred less frequently during the benchmark.
• p99 — the 99th percentile of the input latency in the test run. only 1% of sampled inputs were slower than this. this represents the worst-case scenarios encountered during the benchmark, useful for identifying potential performance outliers.
• blocking time — the total time during which the main thread was blocked, preventing user input and UI updates. this metric helps identify performance bottlenecks that may cause the interface to feel unresponsive.
• test duration — how long the test run took to complete.

[binoy14]

This is great for debugging, thank you!

Tested it locally and matches the expectation