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

making exports git friendly #1409

Merged
merged 2 commits into from Apr 18, 2019

Conversation

Projects
None yet
2 participants
@everplays
Copy link
Contributor

commented Mar 16, 2019

without this, body of a json request looks like the following in the export:

"body": {
  "mimeType": "application/json",
  "text": "{\n\t\"user\": {\n\t\t\"expectation\": \"this is in human readable format\",\n\t\t\"answer\": 42\n\t}\n}"
}

with it:

"body": {
  "mimeType": "application/json",
  "payload": {
    "user": {
      "expectation": "this is in human readable format",
      "answer": 42
    }
  }
}

Why?

We have a couple of workspaces that we have checked into our git repository and we use them as documentation and examples of our APIs. Everything works well until two developers change the body of a request. Even if they do not change the same line in the body (something that git can handle without merge conflict), we still end up with conflicts because the entire body gets collapsed into one line in the export (something that git can NOT handle).

This change ensures that at least for JSON format, not only we will end up with less conflicts but they can be resolved by the developers a lot easier.

What about other formats?

One solution could be to generalize this concept by splitting each line of body. Something like:

"body": {
  "mimeType": "application/json",
  "text": [
    "{",
    "\t\"user\": {",
    "\t\t\"expectation\": \"this is in human readable format\",",
    "\t\t\"answer\": 42",
    "\t}",
    "}"
  ]
}

Even though this is definitely better than putting everything in one line as string, I personally prefer to keep the JSON as currently implemented in this PR (it's odd to modify it when we can just put it in the export).

Backwards compatibility?

Yes, it is backwards compatible.

next?

I'll wait for feedback from you to see which way is preferred then I'll finalize the PR by addressing them and adding tests.

@welcome

This comment has been minimized.

Copy link

commented Mar 16, 2019

💖 Thanks for opening this pull request! 💖

To help make this a smooth process, please be sure you have first read the
contributing guidelines.

@everplays

This comment has been minimized.

Copy link
Contributor Author

commented Mar 28, 2019

@gschier any chance I can get your thoughts on this?

@gschier

This comment has been minimized.

Copy link
Collaborator

commented Apr 7, 2019

This solution seems a bit too specific for my liking since it only works for JSON bodies. What about other fields like request documentation, environments, etc?

I do agree, however, that making exports git-friendly is a good idea. I feel like moving from JSON to something that supports newlines (like YAML or TOML) would be a better way to go.

making exports git friendly
As YAML supports multi line content, each line of requests' body will
appear in separate line when exported. Hence, making the exports git
friendly.

@everplays everplays force-pushed the everplays:making-export-git-friendly branch from ad9cd14 to b9134e2 Apr 8, 2019

@everplays

This comment has been minimized.

Copy link
Contributor Author

commented Apr 8, 2019

@gschier FYI, I opted for YAML.

A few notes:

  • I tried to use js-yaml (existing dependency) and swagger-parser's YAML. However, both of them escaped multi-line outputs so I had to use yaml package which has the desired effect.
  • The git hooks of project changed parts of output.json files that I had not modified. Let me know if you don't want to include them, I can remove the changes and simply commit with hooks disabled.
  • Not sure why but flow check seem to fail with Cannot resolve module 'yaml' even though the dependency is added and app works when I use the interface.

example of output:

  - _id: req_b9bf508ff5334fb186e532d3ebf307b8
    authentication: {}
    body:
      mimeType: application/json
      text: |-
        {
          "user": {
            "expectation": "this is in human readable format",
            "answer": 42
          }
        }
    created: 1552755210960
    description: ""
    headers:
      - id: pair_2fa311bb3ffe44e89aaece13a0e3dd3d
        name: X-random
        value: randomheader
      - id: pair_35828866e07b46ddad56f3ae3abe1344
        name: Content-Type
        value: application/json
    isPrivate: false
    metaSortKey: -1552755210960
    method: GET
    modified: 1552755318342
    name: My Request
    parameters:
      - id: pair_75763f912f114b99af84136bb53bf0c3
        name: BLAH
        value: BLAH
    parentId: wrk_6acc3d77d65041c292a96328a5e1859a
    settingDisableRenderRequestBody: false
    settingEncodeUrl: true
    settingMaxTimelineDataSize: 1000
    settingRebuildPath: true
    settingSendCookies: true
    settingStoreCookies: true
    url: https://example.com/
    _type: request

@everplays everplays marked this pull request as ready for review Apr 16, 2019

@gschier
Copy link
Collaborator

left a comment

Thanks for doing this! I can fix the flow error after merging. It's because there is no definition for the yaml module in the flow-typed folder. I think I'm also going to keep an option to export to JSON since there are people who have written tooling that uses it.

@gschier gschier merged commit 86860e4 into getinsomnia:develop Apr 18, 2019

0 of 2 checks passed

continuous-integration/appveyor/pr Waiting for AppVeyor build to complete
Details
continuous-integration/travis-ci/pr The Travis CI build is in progress
Details
@welcome

This comment has been minimized.

Copy link

commented Apr 18, 2019

Congrats on merging your first pull request! 🎉🎉🎉 You're helping make Insomnia awesome! 🙌

@everplays

This comment has been minimized.

Copy link
Contributor Author

commented Apr 18, 2019

@gschier thanks for taking care of it.

@everplays everplays deleted the everplays:making-export-git-friendly branch Apr 18, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.