fix(cli): explicitly exit workers when they're done

[judofyr]

Description

A Node script only exists once all pending handles/requests are completed. It's quite common for dependencies to open various handles and thus prevent the script for naturally exiting. This changes all the scripts which we run inside worker threads to explicitly exit when they're done.

This impacts the following commands: schema extract, manifest extract, graphql deploy, documents validate, schema validate.

This also now unifies the commands so that they all have a main function.

What to review

schema extract, manifest extract, graphql deploy, documents validate, schema validate.

Testing

I've tested schema extract and manifest extract on a custom Studio linked to this version locally. I've not tested the other ones.

Notes for release

Fixes a case where the commands schema extract, manifest extract, graphql deploy, documents validate or schema validate would never complete.

[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	Jan 9, 2025 2:46pm
performance-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 9, 2025 2:46pm
test-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 9, 2025 2:46pm

2 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
studio-workshop	⬜️ Ignored (Inspect)			Jan 9, 2025 2:46pm
test-next-studio	⬜️ Ignored (Inspect)			Jan 9, 2025 2:46pm

[github-actions]

No changes to documentation

[github-actions]

Component Testing Report Updated Jan 9, 2025 2:50 PM (UTC)

✅ All Tests Passed -- expand for details

File	Status	Duration	Passed	Skipped	Failed
comments/CommentInput.spec.tsx	✅ Passed (Inspect)	1m 5s	15	0	0
formBuilder/ArrayInput.spec.tsx	✅ Passed (Inspect)	12s	3	0	0
formBuilder/inputs/PortableText/Annotations.spec.tsx	✅ Passed (Inspect)	39s	6	0	0
formBuilder/inputs/PortableText/copyPaste/CopyPaste.spec.tsx	✅ Passed (Inspect)	50s	11	7	0
formBuilder/inputs/PortableText/copyPaste/CopyPasteFields.spec.tsx	✅ Passed (Inspect)	0s	0	12	0
formBuilder/inputs/PortableText/Decorators.spec.tsx	✅ Passed (Inspect)	25s	6	0	0
formBuilder/inputs/PortableText/DisableFocusAndUnset.spec.tsx	✅ Passed (Inspect)	14s	3	0	0
formBuilder/inputs/PortableText/DragAndDrop.spec.tsx	✅ Passed (Inspect)	26s	6	0	0
formBuilder/inputs/PortableText/FocusTracking.spec.tsx	✅ Passed (Inspect)	1m 7s	15	0	0
formBuilder/inputs/PortableText/Input.spec.tsx	✅ Passed (Inspect)	1m 28s	21	0	0
formBuilder/inputs/PortableText/ObjectBlock.spec.tsx	✅ Passed (Inspect)	1m 40s	18	0	0
formBuilder/inputs/PortableText/PresenceCursors.spec.tsx	✅ Passed (Inspect)	13s	3	9	0
formBuilder/inputs/PortableText/Styles.spec.tsx	✅ Passed (Inspect)	26s	6	0	0
formBuilder/inputs/PortableText/Toolbar.spec.tsx	✅ Passed (Inspect)	1m 43s	21	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 Thu, 09 Jan 2025 14:52:51 GMT

Benchmark	reference latency of sanity@latest	experiment latency of this branch	Δ (%) latency difference
article (title)	25.0 efps (40ms)	25.0 efps (40ms)	+0ms (-/-%)	✅
article (body)	48.4 efps (21ms)	50.5 efps (20ms)	-1ms (-4.1%)	✅
article (string inside object)	24.7 efps (41ms)	25.0 efps (40ms)	-1ms (-1.2%)	✅
article (string inside array)	22.7 efps (44ms)	21.7 efps (46ms)	+2ms (+4.5%)	✅
recipe (name)	50.0 efps (20ms)	55.6 efps (18ms)	-2ms (-10.0%)	✅
recipe (description)	58.8 efps (17ms)	62.5 efps (16ms)	-1ms (-5.9%)	✅
recipe (instructions)	99.9+ efps (6ms)	99.9+ efps (6ms)	+0ms (-/-%)	✅
synthetic (title)	19.8 efps (51ms)	19.2 efps (52ms)	+2ms (+3.0%)	✅
synthetic (string inside object)	20.0 efps (50ms)	20.0 efps (50ms)	+0ms (-/-%)	✅

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)	40ms	50ms	61ms	390ms	300ms	10.3s
article (body)	21ms	22ms	34ms	79ms	350ms	5.9s
article (string inside object)	41ms	45ms	48ms	62ms	133ms	7.3s
article (string inside array)	44ms	46ms	49ms	204ms	364ms	7.1s
recipe (name)	20ms	22ms	26ms	41ms	0ms	6.5s
recipe (description)	17ms	18ms	22ms	32ms	0ms	4.5s
recipe (instructions)	6ms	7ms	8ms	12ms	0ms	3.0s
synthetic (title)	51ms	53ms	55ms	89ms	230ms	11.5s
synthetic (string inside object)	50ms	52ms	61ms	433ms	384ms	8.1s

🧪 Experiment result

The performance result of this branch

Benchmark	latency	p75	p90	p99	blocking time	test duration
article (title)	40ms	43ms	52ms	434ms	231ms	10.6s
article (body)	20ms	21ms	29ms	191ms	256ms	5.7s
article (string inside object)	40ms	43ms	53ms	105ms	193ms	7.0s
article (string inside array)	46ms	47ms	53ms	217ms	292ms	7.2s
recipe (name)	18ms	19ms	20ms	45ms	0ms	6.4s
recipe (description)	16ms	17ms	18ms	25ms	0ms	4.2s
recipe (instructions)	6ms	8ms	9ms	33ms	0ms	3.1s
synthetic (title)	52ms	55ms	61ms	110ms	489ms	11.5s
synthetic (string inside object)	50ms	51ms	58ms	603ms	1060ms	8.8s

📚 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.

[sgulseth]

lgtm!