Proposal: More Consistent Configurations for Features, Options, and Customizations

[clrall]

More Consistent Configurations for Features, Options, and Customizations

The overall goal of this proposal is to allow more robust constraints and configurations for options and configurations and to make the supported configurations more consistant between Features, options, and customizations. This set of new properties is intended to be fully backwards compatable. Only new properties are listed for ease of review.

It originated based on the way we use (and would like to be able to use) dev containers at Salesforce.

Happy to put up the full PR for these spec changes, but filing an issue first, as per How to Contribute.

Feature

Feature customizations is currently a completely open-ended structure. This is nice for flexibility but can make customizations very hard to consume as the way it is used may vary wildly from Feature to Feature. By associating the path to a customization with configurations for that customization, Features can better constrain and define their customizations.

When trying to use Dev Container Features, there was a strong tendancy for engineers to want to use options for everything, even if it wasn't used in initial set up of the Feature because of the convenience of the configurations that exist for options but not for customizations. This bridges that gap and allows both to be constrained and customized in the same way while maintaining backwards compatability. It's fully optional, so Features that don't want to apply configurations to their customizations do not need to.

Property	Type	Description
customizationConfigurations	Record<string, CustomizationConfigurations>	A map of customizations to its configuration. The JSON path should refer to the customization to be configured. This allows similar configurations on customizations as on options to allow clearer constraints and typing for customizations.

CustomizationConfigurations

The proposed configurations that can be mapped to any customization based on the customization's path. These configurations should match all the same configurations available for options (note: a number of new properies have been proposed for options which are described in detail in that section.)

Property	Type	Description
name	string	A 'human-friendly' display name for the customization.
type	string	Type of the customization. Can be any valid JSON data: "string" or "number" or "boolean" or "array" or "object" type.
proposals	array	A list of suggested string values for the customization. Free-form values are allowed. Omit when using enum.
enums	array	A strict list of allowed string values for the customization. Free-form values are not allowed. Omit when using proposals.
default	string or boolean	Default value for the customization.
description	string	Description for the customization.
keywords	array	List of strings relevant to a user that would search for this customization.
documentationURL	string	Link to relevant documentation for the customization.
maxValues	number	The maximum number of values a user can select for this customization.
validationRegex	string	Regular expression pattern to validate a provided customization value against. It is a schema violation if any values in proposals or enum do not pass the supplied validationRegex.
valueMap	Record<string, ValueDetails>	A map of values to their detailed descriptions and documentation for the customization. These values must be included in either enum or proposals. Not every value needs to be included, only the ones that have associated details.

FeatureOptions

There were a number of general human-friendly configurations that exist for Features but not for options such as name, keywords, and documentationURL that should be added for better consistency and experience.

There are also a few new propeties proposed here: maxValues, delimiter, and validationRegex. Given that options are limited to only string or boolean, there have been a number of Features we've seen internally that end up trying to use string options as a space-separated array. Instead of adding array which would make the spec no longer backwards compatible, these three properities can be used to constrain complex string options with known delimiters, a limit on how many values can be provided, and regex validation for values that are acceptable for that option.

Finally, valueMap allows human-friendly data to be associated with specific values in enum or proposals. This is useful for human-readable value names, or providing keywords, descriptions, or documentation for each value to better allow users to determine which value they want to supply to the option. Not ever value needs to be included in the valueMap, for example: if one of the values in the enum is in "beta" or on the path to becoming deprecated, a Feature might want to specify that description for just one value if the list of values is otherwise self-explanatory.

Property	Type	Description
optionId.name	string	A 'human-friendly' display name for the option.
optionId.keywords	array	List of strings relevant to a user that would search for this option.
optionId.documentationURL	string	Link to relevant documentation for the option.
optionId.maxValues	number	The maximum number of values a user can select for this option.
optionId.delimiter	string	If multiple values can be selected for this option, this is the delimiter that should be used to separate them when they are stored as a single string in the environment variable.
optionId.validationRegex	string	Regular expression pattern to validate a provided option value against. It is a schema violation if any values in proposals or enum do not pass the supplied validationRegex.
optionId.valueMap	Record<string, ValueDetails>	A map of values to their associated 'human-friendly' details. These values must be included in either enum or proposals. Not every value needs to be included, only the ones that have associated details.

ValueDetails

Used for both Options and Customizations, this provides standard human-friendly data to values (used in enums or proposals).

Property	Type	Description
name	string	A 'human-friendly' display name for the option.
description	string	Detailed description of the value.
documentationURL	string	URL to additional documentation or resources about this value.
keywords	array	List of strings relevant to a user that would search for this value.

[Miron-Gomes]

You cannot be a real person. Must be a string too. Talks to a person without knowing anything about his life and educational background. You wrote to much ans said almost nothing. Your text can be summarized in 3 words: string, boleean and array. I don't know anything about internet and codes, but I know how to save a life of a patient with signs If a heart attack, and even so, I don't write texts like yours, showing to all of WHO reads a pure lack of respect for someone that makes mistakes trying to be Nice. Erase It! There's still time! Em ter., 17 de jun. de 2025, 15:50, clrall ***@***.***> escreveu:

…

*clrall* created an issue (devcontainers/spec#588) <#588> More Consistent Configurations for Features, Options, and Customizations The overall goal of this proposal is to allow more robust constraints and configurations for options and configurations and to make the supported configurations more consistant between Features, options, and customizations. This set of new properties is intended to be fully backwards compatable. Only new properties are listed for ease of review. Happy to put up the full PR for these spec changes, but filing an issue first, as per How to Contribute <https://github.com/devcontainers/spec/blob/main/contributing.md>. Feature Feature customizations is currently a completely open-ended structure. This is nice for flexibility but can make customizations very hard to consume as the way it is used may vary wildly from Feature to Feature. By associating the path to a customization with configurations for that customization, Features can better constrain and define their customizations. When trying to use Dev Container Features, there was a strong tendancy for engineers to want to use options for everything, even if it wasn't used in initial set up of the Feature because of the convenience of the configurations that exist for options but not for customizations. This bridges that gap and allows both to be constrained and customized in the same way while maintaining backwards compatability. It's fully optional, so Features that don't want to apply configurations to their customizations do not need to. Property Type Description customizationConfigurations Record<string, CustomizationConfigurations> A map of customizations to its configuration. The JSON path should refer to the customization to be configured. This allows similar configurations on customizations as on options to allow clearer constraints and typing for customizations. CustomizationConfigurations The proposed configurations that can be mapped to any customization based on the customization's path. These configurations should match all the same configurations available for options (note: a number of new properies have been proposed for options which are described in detail in that section.) Property Type Description name string A 'human-friendly' display name for the customization. type string Type of the customization. Can be any valid JSON data: "string" or "number" or "boolean" or "array" or "object" type. proposals array A list of suggested string values for the customization. Free-form values are allowed. Omit when using enum. enums array A strict list of allowed string values for the customization. Free-form values are not allowed. Omit when using proposals. default string or boolean Default value for the customization. description string Description for the customization. keywords array List of strings relevant to a user that would search for this customization. documentationURL string Link to relevant documentation for the customization. maxValues number The maximum number of values a user can select for this customization. validationRegex string Regular expression pattern to validate a provided customization value against. It is a schema violation if any values in proposals or enum do not pass the supplied validationRegex. valueMap Record<string, ValueDetails> A map of values to their detailed descriptions and documentation for the customization. These values must be included in either enum or proposals. Not every value needs to be included, only the ones that have associated details. FeatureOptions There were a number of general human-friendly configurations that exist for Features but not for options such as name, keywords, and documentationURL that should be added for better consistency and experience. There are also a few new propeties proposed here: maxValues, delimiter, and validationRegex. Given that options are limited to only string or boolean, there have been a number of Features we've seen internally that end up trying to use string options as a space-separated array. Instead of adding array which would make the spec no longer backwards compatible, these three properities can be used to constrain complex string options with known delimiters, a limit on how many values can be provided, and regex validation for values that are acceptable for that option. Finally, valueMap allows human-friendly data to be associated with specific values in enum or proposals. This is useful for human-readable value names, or providing keywords, descriptions, or documentation for each value to better allow users to determine which value they want to supply to the option. Not ever value needs to be included in the valueMap, for example: if one of the values in the enum is in "beta" or on the path to becoming deprecated, a Feature might want to specify that description for just one value if the list of values is otherwise self-explanatory. Property Type Description optionId.name string A 'human-friendly' display name for the option. optionId.keywords array List of strings relevant to a user that would search for this option. optionId.documentationURL string Link to relevant documentation for the option. optionId.maxValues number The maximum number of values a user can select for this option. optionId.delimiter string If multiple values can be selected for this option, this is the delimiter that should be used to separate them when they are stored as a single string in the environment variable. optionId.validationRegex string Regular expression pattern to validate a provided option value against. It is a schema violation if any values in proposals or enum do not pass the supplied validationRegex. optionId.valueMap Record<string, ValueDetails> A map of values to their associated 'human-friendly' details. These values must be included in either enum or proposals. Not every value needs to be included, only the ones that have associated details. ValueDetails Used for both Options and Customizations, this provides standard human-friendly data to values (used in enums or proposals). Property Type Description name string A 'human-friendly' display name for the option. description string Detailed description of the value. documentationURL string URL to additional documentation or resources about this value. keywords array List of strings relevant to a user that would search for this value. — Reply to this email directly, view it on GitHub <#588>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BS37MONLPPJQMOYUNLQNPV33EBPP3AVCNFSM6AAAAAB7RA4JKOVHI2DSMVQWIX3LMV43ASLTON2WKOZTGE2TINBVGA4TSMY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[GregIsAtGithub]

 Could someone tell me what this is all about?  Why are people "waiting on getting paid."   What is this really all about. And how do you know Schwartz.  Roman involved?  J and Kron I am disappointed.   Who is Joseph?  Besides lowlife Mr magoo.RIP Yahoo Mail: Search, Organize, Conquer On Wed, Jun 18, 2025 at 2:39 AM, ***@***.***> wrote: Miron-Gomes left a comment (devcontainers/spec#588)You cannot be a real person. Must be a string too. Talks to a person without knowing anything about his life and educational background. You wrote to much ans said almost nothing. Your text can be summarized in 3 words: string, boleean and array. I don't know anything about internet and codes, but I know how to save a life of a patient with signs If a heart attack, and even so, I don't write texts like yours, showing to all of WHO reads a pure lack of respect for someone that makes mistakes trying to be Nice. Erase It! There's still time! Em ter., 17 de jun. de 2025, 15:50, clrall ***@***.***> escreveu:

*clrall* created an issue (devcontainers/spec#588) <#588> More Consistent Configurations for Features, Options, and Customizations The overall goal of this proposal is to allow more robust constraints and configurations for options and configurations and to make the supported configurations more consistant between Features, options, and customizations. This set of new properties is intended to be fully backwards compatable. Only new properties are listed for ease of review. Happy to put up the full PR for these spec changes, but filing an issue first, as per How to Contribute <https://github.com/devcontainers/spec/blob/main/contributing.md>. Feature Feature customizations is currently a completely open-ended structure. This is nice for flexibility but can make customizations very hard to consume as the way it is used may vary wildly from Feature to Feature. By associating the path to a customization with configurations for that customization, Features can better constrain and define their customizations. When trying to use Dev Container Features, there was a strong tendancy for engineers to want to use options for everything, even if it wasn't used in initial set up of the Feature because of the convenience of the configurations that exist for options but not for customizations. This bridges that gap and allows both to be constrained and customized in the same way while maintaining backwards compatability. It's fully optional, so Features that don't want to apply configurations to their customizations do not need to. Property Type Description customizationConfigurations Record<string, CustomizationConfigurations> A map of customizations to its configuration. The JSON path should refer to the customization to be configured. This allows similar configurations on customizations as on options to allow clearer constraints and typing for customizations. CustomizationConfigurations The proposed configurations that can be mapped to any customization based on the customization's path. These configurations should match all the same configurations available for options (note: a number of new properies have been proposed for options which are described in detail in that section.) Property Type Description name string A 'human-friendly' display name for the customization. type string Type of the customization. Can be any valid JSON data: "string" or "number" or "boolean" or "array" or "object" type. proposals array A list of suggested string values for the customization. Free-form values are allowed. Omit when using enum. enums array A strict list of allowed string values for the customization. Free-form values are not allowed. Omit when using proposals. default string or boolean Default value for the customization. description string Description for the customization. keywords array List of strings relevant to a user that would search for this customization. documentationURL string Link to relevant documentation for the customization. maxValues number The maximum number of values a user can select for this customization. validationRegex string Regular expression pattern to validate a provided customization value against. It is a schema violation if any values in proposals or enum do not pass the supplied validationRegex. valueMap Record<string, ValueDetails> A map of values to their detailed descriptions and documentation for the customization. These values must be included in either enum or proposals. Not every value needs to be included, only the ones that have associated details. FeatureOptions There were a number of general human-friendly configurations that exist for Features but not for options such as name, keywords, and documentationURL that should be added for better consistency and experience. There are also a few new propeties proposed here: maxValues, delimiter, and validationRegex. Given that options are limited to only string or boolean, there have been a number of Features we've seen internally that end up trying to use string options as a space-separated array. Instead of adding array which would make the spec no longer backwards compatible, these three properities can be used to constrain complex string options with known delimiters, a limit on how many values can be provided, and regex validation for values that are acceptable for that option. Finally, valueMap allows human-friendly data to be associated with specific values in enum or proposals. This is useful for human-readable value names, or providing keywords, descriptions, or documentation for each value to better allow users to determine which value they want to supply to the option. Not ever value needs to be included in the valueMap, for example: if one of the values in the enum is in "beta" or on the path to becoming deprecated, a Feature might want to specify that description for just one value if the list of values is otherwise self-explanatory. Property Type Description optionId.name string A 'human-friendly' display name for the option. optionId.keywords array List of strings relevant to a user that would search for this option. optionId.documentationURL string Link to relevant documentation for the option. optionId.maxValues number The maximum number of values a user can select for this option. optionId.delimiter string If multiple values can be selected for this option, this is the delimiter that should be used to separate them when they are stored as a single string in the environment variable. optionId.validationRegex string Regular expression pattern to validate a provided option value against. It is a schema violation if any values in proposals or enum do not pass the supplied validationRegex. optionId.valueMap Record<string, ValueDetails> A map of values to their associated 'human-friendly' details. These values must be included in either enum or proposals. Not every value needs to be included, only the ones that have associated details. ValueDetails Used for both Options and Customizations, this provides standard human-friendly data to values (used in enums or proposals). Property Type Description name string A 'human-friendly' display name for the option. description string Detailed description of the value. documentationURL string URL to additional documentation or resources about this value. keywords array List of strings relevant to a user that would search for this value. — Reply to this email directly, view it on GitHub <#588>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BS37MONLPPJQMOYUNLQNPV33EBPP3AVCNFSM6AAAAAB7RA4JKOVHI2DSMVQWIX3LMV43ASLTON2WKOZTGE2TINBVGA4TSMY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Miron-Gomes]

Thank you.

[Miron-Gomes]

Sorry for what I wrote you before. Em qua., 18 de jun. de 2025, 01:51, Miron Cormes Luciano Gomes < ***@***.***> escreveu:

…

You cannot be a real person. Must be a string too. Talks to a person without knowing anything about his life and educational background. You wrote to much ans said almost nothing. Your text can be summarized in 3 words: string, boleean and array. I don't know anything about internet and codes, but I know how to save a life of a patient with signs If a heart attack, and even so, I don't write texts like yours, showing to all of WHO reads a pure lack of respect for someone that makes mistakes trying to be Nice. Erase It! There's still time! Em ter., 17 de jun. de 2025, 15:50, clrall ***@***.***> escreveu: > *clrall* created an issue (devcontainers/spec#588) > <#588> > More Consistent Configurations for Features, Options, and Customizations > > The overall goal of this proposal is to allow more robust constraints and > configurations for options and configurations and to make the supported > configurations more consistant between Features, options, and > customizations. This set of new properties is intended to be fully > backwards compatable. Only new properties are listed for ease of review. > > Happy to put up the full PR for these spec changes, but filing an issue > first, as per How to Contribute > <https://github.com/devcontainers/spec/blob/main/contributing.md>. > Feature > > Feature customizations is currently a completely open-ended structure. > This is nice for flexibility but can make customizations very hard to > consume as the way it is used may vary wildly from Feature to Feature. By > associating the path to a customization with configurations for that > customization, Features can better constrain and define their > customizations. > > When trying to use Dev Container Features, there was a strong tendancy > for engineers to want to use options for everything, even if it wasn't > used in initial set up of the Feature because of the convenience of the > configurations that exist for options but not for customizations. This > bridges that gap and allows both to be constrained and customized in the > same way while maintaining backwards compatability. It's fully optional, so > Features that don't want to apply configurations to their customizations do > not need to. > Property Type Description > customizationConfigurations Record<string, CustomizationConfigurations> A > map of customizations to its configuration. The JSON path should refer to > the customization to be configured. This allows similar configurations on > customizations as on options to allow clearer constraints and typing for > customizations. CustomizationConfigurations > > The proposed configurations that can be mapped to any customization based > on the customization's path. These configurations should match all the same > configurations available for options (note: a number of new properies > have been proposed for options which are described in detail in that > section.) > Property Type Description > name string A 'human-friendly' display name for the customization. > type string Type of the customization. Can be any valid JSON data: > "string" or "number" or "boolean" or "array" or "object" type. > proposals array A list of suggested string values for the customization. > Free-form values are allowed. Omit when using enum. > enums array A strict list of allowed string values for the > customization. Free-form values are not allowed. Omit when using proposals. > default string or boolean Default value for the customization. > description string Description for the customization. > keywords array List of strings relevant to a user that would search for > this customization. > documentationURL string Link to relevant documentation for the > customization. > maxValues number The maximum number of values a user can select for this > customization. > validationRegex string Regular expression pattern to validate a provided > customization value against. It is a schema violation if any values in > proposals or enum do not pass the supplied validationRegex. > valueMap Record<string, ValueDetails> A map of values to their detailed > descriptions and documentation for the customization. These values must be > included in either enum or proposals. Not every value needs to be included, > only the ones that have associated details. FeatureOptions > > There were a number of general human-friendly configurations that exist > for Features but not for options such as name, keywords, and > documentationURL that should be added for better consistency and > experience. > > There are also a few new propeties proposed here: maxValues, delimiter, > and validationRegex. Given that options are limited to only string or > boolean, there have been a number of Features we've seen internally that > end up trying to use string options as a space-separated array. Instead > of adding array which would make the spec no longer backwards > compatible, these three properities can be used to constrain complex string > options with known delimiters, a limit on how many values can be provided, > and regex validation for values that are acceptable for that option. > > Finally, valueMap allows human-friendly data to be associated with > specific values in enum or proposals. This is useful for human-readable > value names, or providing keywords, descriptions, or documentation for each > value to better allow users to determine which value they want to supply to > the option. Not ever value needs to be included in the valueMap, for > example: if one of the values in the enum is in "beta" or on the path to > becoming deprecated, a Feature might want to specify that description for > just one value if the list of values is otherwise self-explanatory. > Property Type Description > optionId.name string A 'human-friendly' display name for the option. > optionId.keywords array List of strings relevant to a user that would > search for this option. > optionId.documentationURL string Link to relevant documentation for the > option. > optionId.maxValues number The maximum number of values a user can select > for this option. > optionId.delimiter string If multiple values can be selected for this > option, this is the delimiter that should be used to separate them when > they are stored as a single string in the environment variable. > optionId.validationRegex string Regular expression pattern to validate a > provided option value against. It is a schema violation if any values in > proposals or enum do not pass the supplied validationRegex. > optionId.valueMap Record<string, ValueDetails> A map of values to their > associated 'human-friendly' details. These values must be included in > either enum or proposals. Not every value needs to be included, only the > ones that have associated details. ValueDetails > > Used for both Options and Customizations, this provides standard > human-friendly data to values (used in enums or proposals). > Property Type Description > name string A 'human-friendly' display name for the option. > description string Detailed description of the value. > documentationURL string URL to additional documentation or resources > about this value. > keywords array List of strings relevant to a user that would search for > this value. > > — > Reply to this email directly, view it on GitHub > <#588>, or unsubscribe > <https://github.com/notifications/unsubscribe-auth/BS37MONLPPJQMOYUNLQNPV33EBPP3AVCNFSM6AAAAAB7RA4JKOVHI2DSMVQWIX3LMV43ASLTON2WKOZTGE2TINBVGA4TSMY> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> >

[GregIsAtGithub]

What is this all about? Yahoo Mail: Search, Organize, Conquer On Thu, Jun 19, 2025 at 5:11 PM, ***@***.***> wrote: Miron-Gomes left a comment (devcontainers/spec#588)Sorry for what I wrote you before. Em qua., 18 de jun. de 2025, 01:51, Miron Cormes Luciano Gomes < ***@***.***> escreveu:

You cannot be a real person. Must be a string too. Talks to a person without knowing anything about his life and educational background. You wrote to much ans said almost nothing. Your text can be summarized in 3 words: string, boleean and array. I don't know anything about internet and codes, but I know how to save a life of a patient with signs If a heart attack, and even so, I don't write texts like yours, showing to all of WHO reads a pure lack of respect for someone that makes mistakes trying to be Nice. Erase It! There's still time! Em ter., 17 de jun. de 2025, 15:50, clrall ***@***.***> escreveu: > *clrall* created an issue (devcontainers/spec#588) > <#588> > More Consistent Configurations for Features, Options, and Customizations > > The overall goal of this proposal is to allow more robust constraints and > configurations for options and configurations and to make the supported > configurations more consistant between Features, options, and > customizations. This set of new properties is intended to be fully > backwards compatable. Only new properties are listed for ease of review. > > Happy to put up the full PR for these spec changes, but filing an issue > first, as per How to Contribute > <https://github.com/devcontainers/spec/blob/main/contributing.md>. > Feature > > Feature customizations is currently a completely open-ended structure. > This is nice for flexibility but can make customizations very hard to > consume as the way it is used may vary wildly from Feature to Feature. By > associating the path to a customization with configurations for that > customization, Features can better constrain and define their > customizations. > > When trying to use Dev Container Features, there was a strong tendancy > for engineers to want to use options for everything, even if it wasn't > used in initial set up of the Feature because of the convenience of the > configurations that exist for options but not for customizations. This > bridges that gap and allows both to be constrained and customized in the > same way while maintaining backwards compatability. It's fully optional, so > Features that don't want to apply configurations to their customizations do > not need to. > Property Type Description > customizationConfigurations Record<string, CustomizationConfigurations> A > map of customizations to its configuration. The JSON path should refer to > the customization to be configured. This allows similar configurations on > customizations as on options to allow clearer constraints and typing for > customizations. CustomizationConfigurations > > The proposed configurations that can be mapped to any customization based > on the customization's path. These configurations should match all the same > configurations available for options (note: a number of new properies > have been proposed for options which are described in detail in that > section.) > Property Type Description > name string A 'human-friendly' display name for the customization. > type string Type of the customization. Can be any valid JSON data: > "string" or "number" or "boolean" or "array" or "object" type. > proposals array A list of suggested string values for the customization. > Free-form values are allowed. Omit when using enum. > enums array A strict list of allowed string values for the > customization. Free-form values are not allowed. Omit when using proposals. > default string or boolean Default value for the customization. > description string Description for the customization. > keywords array List of strings relevant to a user that would search for > this customization. > documentationURL string Link to relevant documentation for the > customization. > maxValues number The maximum number of values a user can select for this > customization. > validationRegex string Regular expression pattern to validate a provided > customization value against. It is a schema violation if any values in > proposals or enum do not pass the supplied validationRegex. > valueMap Record<string, ValueDetails> A map of values to their detailed > descriptions and documentation for the customization. These values must be > included in either enum or proposals. Not every value needs to be included, > only the ones that have associated details. FeatureOptions > > There were a number of general human-friendly configurations that exist > for Features but not for options such as name, keywords, and > documentationURL that should be added for better consistency and > experience. > > There are also a few new propeties proposed here: maxValues, delimiter, > and validationRegex. Given that options are limited to only string or > boolean, there have been a number of Features we've seen internally that > end up trying to use string options as a space-separated array. Instead > of adding array which would make the spec no longer backwards > compatible, these three properities can be used to constrain complex string > options with known delimiters, a limit on how many values can be provided, > and regex validation for values that are acceptable for that option. > > Finally, valueMap allows human-friendly data to be associated with > specific values in enum or proposals. This is useful for human-readable > value names, or providing keywords, descriptions, or documentation for each > value to better allow users to determine which value they want to supply to > the option. Not ever value needs to be included in the valueMap, for > example: if one of the values in the enum is in "beta" or on the path to > becoming deprecated, a Feature might want to specify that description for > just one value if the list of values is otherwise self-explanatory. > Property Type Description > optionId.name string A 'human-friendly' display name for the option. > optionId.keywords array List of strings relevant to a user that would > search for this option. > optionId.documentationURL string Link to relevant documentation for the > option. > optionId.maxValues number The maximum number of values a user can select > for this option. > optionId.delimiter string If multiple values can be selected for this > option, this is the delimiter that should be used to separate them when > they are stored as a single string in the environment variable. > optionId.validationRegex string Regular expression pattern to validate a > provided option value against. It is a schema violation if any values in > proposals or enum do not pass the supplied validationRegex. > optionId.valueMap Record<string, ValueDetails> A map of values to their > associated 'human-friendly' details. These values must be included in > either enum or proposals. Not every value needs to be included, only the > ones that have associated details. ValueDetails > > Used for both Options and Customizations, this provides standard > human-friendly data to values (used in enums or proposals). > Property Type Description > name string A 'human-friendly' display name for the option. > description string Detailed description of the value. > documentationURL string URL to additional documentation or resources > about this value. > keywords array List of strings relevant to a user that would search for > this value. > > — > Reply to this email directly, view it on GitHub > <#588>, or unsubscribe > <https://github.com/notifications/unsubscribe-auth/BS37MONLPPJQMOYUNLQNPV33EBPP3AVCNFSM6AAAAAB7RA4JKOVHI2DSMVQWIX3LMV43ASLTON2WKOZTGE2TINBVGA4TSMY> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> >

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[chrmarti]

@clrall Thanks for filing this proposal!

Just to clarify the intent of the existing customizations property: This is meant for other tools to have their configuration included (e.g., VS Code includes its settings and extensions there). Each tool can pick a sufficiently distinct property name under customizations and add its configuration underneath that. The way we are using it keeps the schema of these tools configurations the same across all devcontainer-feature.json (and devcontainer.json since that has the same customizations).

Since you are interested in configuration for a specific feature the existing options seem like the best way to capture that. I agree that changing these will potentially break backwards compatibility and depending on the nature of the breakage we might need to come up with a way to mitigate it.

[abl]

The goal was to allow features to comprehensively specify what options they make available without relying on conventions (like "this string field will be interpreted as an array split on whitespace") which will allow for richer validation and a better UX (i.e. no awkward bugs when a valid identifier has a space in it). Salesforce perhaps has a unique situation where almost everyone uses the same devcontainer but the selected features, and the configurations thereof, vary wildly.

For backwards compatibility, as far as I understood the proposal, these advanced options gracefully decay; clients are free to ignore the additional constraints and will instead get runtime failures.

One proposal I'd discussed was breaking away completely from the options property since it's tightly coupled to environment variables and merging everything into customizations - this introduces a namespacing constraint which is solvable but still leaves a question of where features should communicate what their constraints and configuration are.