How to move forward with a code review

[scriptjs]

Hi, I have generated a pull request #571to modify the features schema and also added a proposal and examples of how extending the schema can facilitate feature development. I would like this committed to the repo. There is very little activity in the repo and I am also seeing spam in the issues that no one has cleaned up. Can someone who is administering this repo please review my submission. @bamurtaugh @Chuxel

[scriptjs]

I have made the proposal and pull request some time ago. I have answered all questions concerning the pull request, but there is no movement forward. I am not sure who is looking after this project but I would appreciate progress with the pull request as I don't want to fork but contribute to this project to use my changes.

[bamurtaugh]

Hi there, thank you for following up! Just to double check - are you referring to #571? I still see a couple open questions there from a May 5 PR review.

[scriptjs]

Hi @bamurtaugh, yes. I answered those questions. There has been no response to my answers so we can move forward.

[bamurtaugh]

I think I may be missing where the answers happened. For instance, I'm not sure where your response to the comment #571 (comment) is - could you please link it here? Thanks so much!

[scriptjs]

I am copying what I am seeing because I don't understand why it is not visible. The links are embeded: scriptjs started a review
Pending
proposals/add-array-object-feature-option-types.md

Proposed Solution

Extend the Dev Container Feature Options Schema by introducing array and object as valid types for feature options. These new types will enable developers to create more complex and customizable features.
Author
@scriptjs scriptjs Pending
Great question! While limiting values to just strings and booleans would keep things simple, supporting arrays and objects actually opens up much more flexibility for feature authors. For example, arrays let you specify lists of packages or ports, and objects make it easy to define key-value pairs—like environment variables or configuration blocks.

Based on the proposal and the examples, the supported value types would include:

strings (for single values, like a name or path),
booleans (for simple on/off options),
arrays (for lists of values, like dependencies or ports), and
objects (for key-value maps, such as sets of environment variables or settings).
This broader support means features can remain simple but also become more powerful, without resorting to awkward workarounds or string parsing. It gives developers the tools they need to create richer, more configurable features, while still allowing for straightforward use cases. If simplicity is a priority, you can always stick to strings and booleans—but having arrays and objects as options makes the schema much more adaptable for everyone!

proposals/add-array-object-feature-option-types.md

Install dependencies

echo "Installing dependencies..."
for package in "${DEPENDENCIES[@]}"; do
Author
@scriptjs scriptjs Pending
While it’s true that using Bash-specific syntax (such as arrays and associative arrays) limits compatibility with minimal shells like /bin/sh, it’s also important to recognize that not all features are public or intended for universal environments. Feature developers should not be restricted to POSIX shell syntax if their use case benefits from Bash’s advanced features.

Allowing Bash syntax gives feature authors more expressive power and flexibility—especially for complex logic, data structures (arrays/objects), and maintainability. The choice of shell should be left to the feature author, depending on their target audience and platform requirements. Imposing strict /bin/sh compatibility on all features can be unnecessarily limiting for those who are able and willing to depend on Bash, or who are building features for environments where Bash is always available.

In summary: while POSIX compatibility is valuable for broad compatibility, there are valid cases where leveraging Bash-specific features is the pragmatic and efficient choice for feature development. Feature authors should be empowered to choose the best tool for their use case.

proposals/add-array-object-feature-option-types.md

Install dependencies

echo "Installing dependencies..."
for package in "${DEPENDENCIES[@]}"; do
Author
@scriptjs scriptjs Pending
Just an addition piece to my comment is that documentation can be enhanced for devcontainers to discuss feature syntax and universality relating to bash use. I know for myself, it's painful for this to be restricted.

proposals/add-array-object-feature-option-types.md

Install dependencies

echo "Installing dependencies..."
for package in "${DEPENDENCIES[@]}"; do
Author
@scriptjs scriptjs Pending
Note, the current feature documentation is below. This confirms what I have indicated about feature developer choice in how features may be developed. While universality may be a goal with minimal shells, authoring is not limited to them. The json schema must match the expressiveness of the goals identified in the documentation. "should" is also not "must" with respect to /bin/sh, and for universality, the default has been expressed in the documentation already. Any deviation should be identified in feature metadata.

Authoring
Features can be authored in a number of languages, the most straightforward being bash scripts. If a Feature is authored in a different language information about it should be included in the metadata so that users can make an informed choice about it.

Reference information about the application required to execute the Feature should be included in devcontainer-feature.json in the metadata section.

Applications should default to /bin/sh for Features that do not include this information.

If the Feature is included in a folder as part of the repository that contains devcontainer.json, no other steps are necessary.

[scriptjs]

@bamurtaugh All of the pending content is at #571 (comment)

[White01-bot1]

What do I need to do?

…

On Fri, Jul 11, 2025, 2:06 AM scriptjs ***@***.***> wrote: @bamurtaugh <https://github.com/bamurtaugh> All of the pending content is at #571 (comment) <#571 (comment)> — Reply to this email directly, view it on GitHub <#573 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BTOC3AN5DF5CX2TCRKFV6AL3H4E2HAVCNFSM6AAAAAB3W4JG6GVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGNZSGY3DMNI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>