-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change bunfig.toml to bun.json #1805
Comments
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) |
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 |
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. 🐱 |
Does this schema exist yet? (Came here from Google looking for one) |
How about a code config file? |
We generally want to avoid any config which has to be interpreted/executed (for instance, JavaScript). That's because it will increase startup time. |
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
<#1805 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIPXJVR5JIV7AJYCVY2BZ3YYDX67AVCNFSM6AAAAAAT5DPOV6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJWGE4TSOBRHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
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. |
Another benefit of TS/JS config is that it enables easily shareable configs via npm package. |
Let me also give a concrete example why
|
Hello, I recently created a schema for |
No description provided.
The text was updated successfully, but these errors were encountered: