Skip to content
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

TOML Support #1303

Open
3 tasks
helloanoop opened this issue Dec 30, 2023 · 11 comments
Open
3 tasks

TOML Support #1303

helloanoop opened this issue Dec 30, 2023 · 11 comments

Comments

@helloanoop
Copy link
Contributor

Overview

This discussion aims to explore the possibility of using .toml as the preferred format for saving API request data instead of .bru. For the progression of the Domain-Specific Language (DSL), see #360

I've been seriously exploring how we can represent api requests in toml
After careful consideration, factoring in various edge cases, toml seems to fulfil our requirements and might offer better long-term benefits.

Why TOML

  • Well established format
  • Utilize syntax highlighting in IDEs
  • Leverage existing tooling for toml file manipulation
  • Git providers (like GitHub, Bitbucket) offer syntax highlighting while reviewing pull requests on the web

Tasks

  • Experimental support for working with TOML in GUI
  • Experimental support for working with TOML in CLI
  • Gather Community feedback during our community call on Wed Jan 3rd 2024

More Tasks TBD based on how the experiment turns out

Looming Issues

Several features are currently blocked due to limitations in the bru language. Some include:

  1. Describing headers
  2. Managing choices for query parameters
  3. File upload capabilities
  4. Storing multiple payloads within a single request

To address these limitations, I see two potential paths:

  1. Enhance Bru Lang
  2. Utilize TOML

Next Steps

Before choosing a direction, I aim to implement experimental TOML support in our current app within the next 3-4 days (by January 1st, 2024). . BTW I am working on bruno Full Time from Jan 1st :)

Sample GET Request

image

@kishaningithub
Copy link

I feel that TOML should be the way forward. Would appreciate more articles on TOML vs bru as you move forward with the next steps.

@nateshmbhat
Copy link

any update on this ? this seems very interseting

@hp77-creator
Copy link

Hey @helloanoop, just wanted to know did you also explore/consider YAML for the language?

@hp77-creator
Copy link

Hey @helloanoop, just wanted to know did you also explore/consider YAML for the language?

My bad, went through #360 , indentation hell 🤔 interesting, I mean at one point it can become that but then at that point your API design is not good, It will be on the type of API imo.

@jzorn
Copy link
Contributor

jzorn commented Mar 21, 2024

I think TOML is a better format for humans. It's too easy to mess things up in YAML.

@helloanoop helloanoop unpinned this issue Mar 31, 2024
@DenisMir
Copy link

DenisMir commented Aug 2, 2024

Any progress on this? There are so much bugs just going back to the custom bru DSL. It would be awesome to get rid of all of them. (e.g. the colon bug)

@helloanoop
Copy link
Contributor Author

We will move very soon (max 2 weeks) to support YAML to save the requests

@lohxt1 on our team is already working on it.
There is a lot of nuance on TOML support, I will add detailed notes later

TLDR; - YAML support to arrive soon, TOML will need more time

@aarjithn
Copy link

@helloanoop my 2c is to stick with just one. If its yaml so be it. Who are very particular can setup conversion to/from toml

Maybe depreciate and support bru for a while but going down path of multiple config languages would be a pain

@skhaz
Copy link

skhaz commented Aug 12, 2024

I do not think a custom language for settings a good idea.

Please try to stick to toml or yaml, do not reinvent the wheel.

@DenisMir
Copy link

Yeah. E.g. not allowing to have "colons" in your custom format for values is a bad joke. That is why inventing some custom configuration format is definitely a pain and just leads to bugs that normally would not be a problem with a basic standard format.

@mabramo
Copy link

mabramo commented Nov 14, 2024

I agree one standard should be developed for. Bru is nice, with some issues. Personally I much prefer TOML over YAML as I find it easier to read.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants