feat(cli): add `schemaId` flag for initialising projects from schema builder

[RostiMelk]

Description

This PR adds a hidden schemaId flag to the CLI, specifically for the init command. This flag allows a user to initialize a project from the schema builder, overring the default behavior of prompting the user for a template.

This was initially supposed to be a hidden flag, but after discussion I have added a new help text to the init command

--schemaId <schemaId>: Init studio from a Schema Builder schema. Start your schema design at: https://schema.club. (alpha)

What to review

Run sanity init --schemaId ZaEh6uHn and verify that the project is initialized from the schema builder.

Notes for release

~No notes for release. This is a hidden flag, so it should not be documented in the CLI help.~

[vercel[bot]]

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

Name	Status	Preview	Comments	Updated (UTC)
performance-studio	✅ Ready (Inspect)	Visit Preview		Dec 13, 2023 0:49am
test-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Dec 13, 2023 0:49am

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
studio-workshop	⬜️ Ignored (Inspect)	Visit Preview		Dec 13, 2023 0:49am

[github-actions[bot]]

Package	Documentation Change
sanity	-3%

Full Report

@sanity/diff

This branch	Next branch
13 documented	13 documented
16 not documented	16 not documented

@sanity/block-tools

This branch	Next branch
4 documented	4 documented
9 not documented	9 not documented

@sanity/types

This branch	Next branch
54 documented	54 documented
235 not documented	235 not documented

sanity/desk

This branch	Next branch
85 documented	85 documented
60 not documented	60 not documented

@sanity/portable-text-editor

This branch	Next branch
21 documented	21 documented
44 not documented	44 not documented

@sanity/mutator

This branch	Next branch
7 documented	7 documented
4 not documented	4 not documented

@sanity/cli

This branch	Next branch
1 documented	1 documented
30 not documented	30 not documented

@sanity/schema/_internal

This branch	Next branch
0 documented	0 documented
9 not documented	9 not documented

@sanity/util/paths

This branch	Next branch
1 documented	1 documented
15 not documented	15 not documented

sanity/router

This branch	Next branch
17 documented	17 documented
26 not documented	26 not documented

@sanity/util/legacyDateFormat

This branch	Next branch
0 documented	0 documented
3 not documented	3 not documented

@sanity/schema

This branch	Next branch
0 documented	0 documented
2 not documented	2 not documented

sanity/cli

This branch	Next branch
2 documented	2 documented
0 not documented	0 not documented

@sanity/vision

This branch	Next branch
0 documented	0 documented
3 not documented	3 not documented

@sanity/util/fs

This branch	Next branch
0 documented	0 documented
3 not documented	3 not documented

sanity/_internal

This branch	Next branch
0 documented	0 documented
1 not documented	1 not documented

@sanity/util/content

This branch	Next branch
1 documented	1 documented
5 not documented	5 not documented

sanity

This branch	Next branch
169 documented	176 documented
837 not documented	844 not documented

[github-actions[bot]]

Component Testing Report Updated Dec 13, 2023 12:50 PM (UTC)

File	Status	Duration	Passed	Skipped	Failed
comments/CommentInput.spec.tsx	✅ Passed (Inspect)	14s	15	0	0
formBuilder/ArrayInput.spec.tsx	✅ Passed (Inspect)	2s	3	0	0
formBuilder/inputs/PortableText/Annotations.spec.tsx	✅ Passed (Inspect)	8s	3	0	0
formBuilder/inputs/PortableText/Decorators.spec.tsx	✅ Passed (Inspect)	6s	6	0	0
formBuilder/inputs/PortableText/FocusTracking.spec.tsx	✅ Passed (Inspect)	15s	15	0	0
formBuilder/inputs/PortableText/Input.spec.tsx	✅ Passed (Inspect)	8s	9	0	0
formBuilder/inputs/PortableText/ObjectBlock.spec.tsx	✅ Passed (Inspect)	38s	18	0	0
formBuilder/inputs/PortableText/Styles.spec.tsx	✅ Passed (Inspect)	6s	6	0	0
formBuilder/inputs/PortableText/Toolbar.spec.tsx	✅ Passed (Inspect)	3s	3	0	0

[kmelve]

Would --schemaId be more intuitive? It's not the “builder” that you're IDing. And folk's mental model here is that they have a "schema" they want to add to the studio?

[jtpetty]

Would --schemaId be more intuitive? It's not the “builder” that you're IDing. And folk's mental model here is that they have a "schema" they want to add to the studio?

I agree with that. Also, this is an open source repo so nothing is truly "hidden". Is there a way to explicitly add a comment that this flag is experimental and should not be used externally? Not documenting something is ambiguous. Is it not documented to "hide" it or is it not documented because someone forgot to document it? Being explicit is preferred in this situation I think.

[RostiMelk]

Would --schemaId be more intuitive? It's not the “builder” that you're IDing. And folk's mental model here is that they have a "schema" they want to add to the studio?

Renamed now.

[RostiMelk]

Would --schemaId be more intuitive? It's not the “builder” that you're IDing. And folk's mental model here is that they have a "schema" they want to add to the studio?

I agree with that. Also, this is an open source repo so nothing is truly "hidden". Is there a way to explicitly add a comment that this flag is experimental and should not be used externally? Not documenting something is ambiguous. Is it not documented to "hide" it or is it not documented because someone forgot to document it? Being explicit is preferred in this situation I think.

Added helper

[jtpetty]

Would --schemaId be more intuitive? It's not the “builder” that you're IDing. And folk's mental model here is that they have a "schema" they want to add to the studio?

I agree with that. Also, this is an open source repo so nothing is truly "hidden". Is there a way to explicitly add a comment that this flag is experimental and should not be used externally? Not documenting something is ambiguous. Is it not documented to "hide" it or is it not documented because someone forgot to document it? Being explicit is preferred in this situation I think.

Added helper

My apologies, my intention wasn't to add it to the help text, but to document it in the code that we are explicitly not officially supporting this yet. This is an experiment and maybe down the road we officially support it once schema club is out of alpha.

[RostiMelk]

Would --schemaId be more intuitive? It's not the “builder” that you're IDing. And folk's mental model here is that they have a "schema" they want to add to the studio?

I agree with that. Also, this is an open source repo so nothing is truly "hidden". Is there a way to explicitly add a comment that this flag is experimental and should not be used externally? Not documenting something is ambiguous. Is it not documented to "hide" it or is it not documented because someone forgot to document it? Being explicit is preferred in this situation I think.

Added helper

My apologies, my intention wasn't to add it to the help text, but to document it in the code that we are explicitly not officially supporting this yet. This is an experiment and maybe down the road we officially support it once schema club is out of alpha.

Ah okay, this makes a lot more sense. I'll do that, thanks 👍