Change bunfig.toml to bun.json

[Jarred-Sumner]

[Zeko369]

I'm really interested in the reasoning here (any tweet threads / notes on why)?

Or is it just familiarity in the JS ecosystem + easier schema/autocomplete? (not sure if there is a JSON-schema TOML equivalent)

[b-fett]

Actually, when i installed bun extension in vscode, i also expected autocompletions for configuration file.

And for json it's made quite simple: https://code.visualstudio.com/api/references/contribution-points#contributes.jsonValidation

[00dani]

The JSON Schema format can actually be used to specify TOML (and YAML) configuration files as well with no major issues, since the data structures being described are close enough to being the same.

For example, Starship's TOML configuration file comes with an associated schema, and that schema can be used to validate and autocomplete your configuration with the appropriate tooling in your editor. Similarly there are a range of schemata available for YAML configuration files such as kustomization.yaml and yamllint.yaml.

Providing a suitable JSON Schema for bunfig.toml should enable the autocompletion @b-fett was hoping for, without needing to actually change the configuration format to JSON if TOML is still preferred for its human-friendliness. 🐱

[mnpenner]

Does this schema exist yet? (Came here from Google looking for one)

[silverwind]

How about a code config file? bun.config.ts / bun.config.js. Very flexible but it could present a chicken-and-egg problem 😆.

[Electroid]

How about a code config file? bun.config.ts / bun.config.js. Very flexible but it could present a chicken-and-egg problem 😆.

We generally want to avoid any config which has to be interpreted/executed (for instance, JavaScript). That's because it will increase startup time.

[mnpenner]

JS/TS files are also annoying for other tools that want to integrate. For example, I've wanted to tinker with some Babel configs before feeding it back to Babel but it's really hard to do when they have several different formats. Also my IDE likes to read configs to provide better tooling support and I bet they wouldn't be thrilled about having to execute another config file either.

On Wed, Mar 13, 2024, 5:50 PM Ashcon Partovi @.***> wrote:

How about a code config file? bun.config.ts / bun.config.js. Very flexible but it could present a chicken-and-egg problem 😆.

We generally want to avoid any config which has to be interpreted/executed (for instance, JavaScript). That's because it will increase startup time.

— Reply to this email directly, view it on GitHub https://github.com/oven-sh/bun/issues/1805#issuecomment-1996199818, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIPXJVR5JIV7AJYCVY2BZ3YYDX67AVCNFSM6AAAAAAT5DPOV6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJWGE4TSOBRHA . You are receiving this because you commented.Message ID: @.***>

[jasongitmail]

Looks like they have a good reason to stick with what they have.

But to disagree with the comment above, more and more JS tooling now allows for js/ts configs (e.g. eslint & prettier enabled it recently, Playwright, Jest, framework configs, etc). The benefit of JS/TS is easier reuse of a common config among multiple projects, to provide consistency across projects within an organization, bc they can be exported and imported easily. As opposed to needing to copy & paste and then having them eventually become inconsistent across repos. This is a big benefit.

[silverwind]

Another benefit of TS/JS config is that it enables easily shareable configs via npm package.

[silverwind]

Let me also give a concrete example why bun.config.ts is needed: In Vitest, I like to configure the snapshot directory path via resolveSnapshotPath function. While bun does not have this option yet, it would never be possible to do with a non-code config format.

.config.ts files are already a quasi-standard among modern JS/TS tooling, and I definitely think bun should follow too.