Allow for an official plugin to allow for customizing the devbox manifest file.

[CourteousCoder]

What problem are you trying to solve?

Allow arbitrary custom configs via an official plugin.

Summary

There are a lot of requests for allowing support for different configuration languages for devbox.json, such as JSONC,YAML, TOML, etc. But Devbox already includes a plugin API that allows for adding custom options to devbox.json

Related

Generalizes and might also resolve: #1590, #2169, #2602, #2480

What solution would you like?

Add support for custom manifest files, e.g. by opt-in plugins that to hook into whatever modules handle interact with devbox.json directly. Then we could achieve something like this.

(or devbox.jsonc or devbox.toml)

{
  # These are comments made with `#` because its yaml not jsonc
  "name": "",
  "version": "",
  "description": "",
  "packages": [], # or {} of packages
  "env": { "<key>": "<value>" },
  "create_files": {},
  # "<destination>": "<source>"
  "shell": {
      "init_hook": [],
      # "<bash commands>"
      "scripts": { "<key>": "<value>" },
    },
  "include": ["<path_to_plugin>"],
}

which could then be refactored to a devbox.yaml like this

name: ExampleDevboxYaml# name of your devbox shell
version: 0.0.1 # your project version
description: This is an example devbox configured with yaml
packages:
  - someNixPkgs
  - github:someFlake
  - fooPackages.bar@version^out,dev,
env:
  SOME_ENV_VAR: someValue
create_files:
  "./destination/of/file": ./source/of/file
shell:
  init_hook:
    - echo 'some bash commands'
    - echo 'or a multiline string justl like you would see with ci programs e.g. github actions'
scripts:
  someKey: someValue
include:
  - ./path/to/plugin

Alternatives you've considered

Alternative 1: Mode directive, separate .scripts directory, reconfiguring your IDE

See this, my comment here.
Originally posted by @CourteousCoder in #2602

This is my current solution.

Alternative 2: Custom plugin with additional config file

Create a community-maintained custom plugin that provides an additional config file.

This might be A more flexible long-term solution. In theory, it provides an indirect way to use a different config language.

Then, devbox.json would theoretically still be the only configuration file devbox looks for.

I think we might already have a way to implement this with the existing plugin API. I have not verified this.

Based on the current plugin API (Wayback Machine archive), I don't see why a plugin couldn't adhere to the devbox schema and then utilize its own config file (e.g. a plugin:yaml could manage to utilize a devbox.yaml and implement the same schema as devbox.json, but in yaml.

There might be a corner case where another external plugin, script, or utility reads to or writes from devbox.json directly. That might break compatibility with a yaml format.

But basically your devbox.json would be merely:

{
 "$schema": "https://raw.githubusercontent.com/jetify-com/devbox/0.14.2/.schema/devbox.schema.json",

  "include": [
      // or perhaps "plugin:devbox-yaml", or even "plugin:yaml" for brevity
      // or for whatever kind of config language support you want.
      // "plugin:toml",
      // "plugin:jsonc",
      // "plugin:dhall",
      // ...
      "plugin:manifest-yaml",
  ]
}

And then you could put the yaml configuration into devbox.d/manifest-yaml/devbox.yaml, or perhaps configure the plugin to look for devbox.yaml in the root of the project.

Alternative 3: Hardlink (JSONC only)

A horrible idea in my opinion. But it is an option, I suppose.

Maintain an automated hardlink between devbox.jsonc and devbox.json and add devbox.json to .gitignore

Alternative 4: Preprocessing

Write some sort of adapter, wrapper, pre-commit hook, plugin, or service to synchronize devbox.json with some devbox.yaml, devbox.toml, devbox.jsonc

Cumbersome and against the design goal of devbox to simplify nix configs for development environments.

This is one of the main use cases of DHALL. A really cool config language in opinion. However, I don't think it really resolves the related issues I've referenced here, nor aligns with devbox's design goals of having a sugary and familiar dev UX around nix.