[Feature Request] Allow configuration of Starship via feature options

[ice-perseus]

It would be very helpful to be able to configure Starship directly through the devcontainer.json feature options.

I'm not an expert on how features are built, but my assumption is that the empty object in the feature definition (the inner curly braces) is the place for these options:

"features": {
    "ghcr.io/schlich/devcontainer-features/starship:0": {
        // Options would go here (maybe)
    }
}

Would it be possible to add support for this?

The official Starship documentation lists all available configuration parameters: https://starship.rs/config/

I believe the implementation would involve taking the options provided in devcontainer.json and using them to generate the ~/.config/starship.toml file during the feature's installation script.

Thank you for considering this request!

[schlich]

hi @ice-perseus , thanks for the feature request!

Happy to start working on this but curious about your use case. It would be significantly easier to setup some sort of configuration for the devcontainer initialization that correctly ports an existing starship.toml file, rather than manually hand-code the handling of individual configuration options (which seem likely to be frequently-changing anyways).

questions:

1. Would a solution that revolves around configuring an existing starship.toml suit your needs?
2. If not, are there particular options you'd like to see prioritized if hand-porting the configuration options turns out to be necessary?

[schlich]

follow-up thought: if you happen to be looking for a per-project configuration, one solution might be to include a starship.toml in your repo and use the remoteEnv field in devcontainer.json to manually set a path relative to your ${containerWorkspaceFolder} or similar. Another option might be to mount the host starship.toml into the container's ~/.config directory. (see the dev container spec if you need pointers on how to configure all that).

Let me know if that makes sense or you'd like clarification, I'll continue to ponder what a clean way to implement this in the dev container feature might be, but please do chime in with thoughts or concerns.

[ice-perseus]

My use case is pretty straightforward: I work on multiple projects in different languages, and to keep my main system clean I usually drop in my own devcontainer.json files when cloning a new project (depending on the stack).

I like Starship a lot more than the default prompt, but there are two things that bother me:

• I’d like to see the full path directly in the prompt, without having to run pwd.
• I prefer having a $ instead of > in the prompt. It makes copied snippets clearer, since it shows the commands are being run as a regular user and not as root.

I know these options can be configured in config.toml - I’ve already checked that. But keeping an extra config file around feels inconvenient, since it’s just another thing I’d have to copy. Using devcontainer.json as a single source of truth seems like a much cleaner solution.

That said, I don’t think this should be tailored to my personal setup. A better approach would be to make it universal and support all config.toml parameters, so that everyone can adjust it the way they want.

Thanks!

[schlich]

thanks @ice-perseus , my question about prioritization was less about tailoring the features to your individual use cases and more getting an idea of what sorts of options you might need to decide on an approach, and your response definitely helped in that regard, since I can figure i can start with the prompt-specific configuration options. Unless i discover a clear pattern that i can derive from the starship cli output or a published spec, it would likely be too much work to configure every single tool-specific option by hand.

In any case, I've opened a branch and will provide updates.