From d95c6523ffca600ae7a4e8383989a800e9f73da0 Mon Sep 17 00:00:00 2001 From: Kyle Shockey Date: Mon, 24 Jul 2017 23:30:31 -0700 Subject: [PATCH 1/9] Add CONTRIBUTING.md --- CONTRIBUTING.md | 54 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 54 insertions(+) create mode 100644 CONTRIBUTING.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 00000000..8ee83573 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,54 @@ +## Contributing to Swagger-UI + +#### Environment setup + +0. Install Node.js (4 or newer) and npm (3 or newer). +1. Fork Swagger-UI, and clone your fork. +2. Run `npm install` in your Swagger-UI directory. +3. Run `npm run dev`. `localhost:3200` should open automatically. +4. You're ready to go! + +#### Branching model + +Feature branches should be prefixed with `ft/`. + +Bugfix branches should be prefixed with `bug/`. + +After the forward slash, include a short description of what you're fixing. For example: `bug/fix-everything-that-was-broken`. + +If there's an issue filed that you're addressing in your branch, include the issue number directly after the forward slash. For example: `bug/1234-fix-all-the-other-things`. + +#### Filing issues + +- **Do** include the Swagger-UI build you're using - you can find this by opening your console and checking `window.versions.swaggerUi` +- **Do** include a spec that demonstrates the issue you're experiencing. +- **Do** include screenshots, if needed. GIFs are even better! +- **Do** place code inside of a pre-formatted container by surrounding the code with triple backticks. +- **Don't** open tickets discussing issues with the Swagger/OpenAPI specification itself, or for issues with projects that use Swagger-UI. +- **Don't** open an issue without searching the issue tracker for duplicates first. + +#### Committing + +- Break your commits into logical atomic units. Well-segmented commits make it _much_ easier for others to step through your changes. +- Limit your subject (first) line to 50 characters (GitHub truncates more than 70). +- Provide a body if you'd like to explain your commit in detail. +- Separate the subject from the body with a blank line, for readability. +- Capitalize the beginning of your subject line. +- Do not end the subject line with a period. +- Use the imperative mood in your subject lines, as if you were giving the code an order in your subject line. + - This mimics what Git does for you automatically: "Merge develop", "Revert f570ffc", etc + - Simple trick... your subject line should complete this sentence: `If applied, this commit will [your subject line].` +- Don't use [magic GitHub words]() in your commits to close issues - do that in the pull request for your code instead. + +_Adapted from [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/#seven-rules)._ + +#### Making pull requests + +- **Do** summarize your changes in the PR body. If in doubt, write a bullet-point list titled `This PR does the following:`. +- **Do** include references to issues that your PR solves, and use [magic GitHub words]() to close those issues automatically when your PR is merged. +- **Do** include tests that cover new or changed functionality. +- **Do** be careful to follow our ESLint style rules. We recommend installing an ESLint plugin if you use a graphical code editor. +- **Do** make sure that tests and the linter are passing by running `npm test` locally, otherwise we can't merge your pull request. +- **Don't** include any changes to files in the `dist/` directory - we update those files only during releases. +- **Don't** mention maintainers in your original PR body - we probably would've seen it anyway, so it just increases the noise in our inboxes. Do feel free to ping maintainers if a week has passed and you've heard nothing from us. +- **Don't** open PRs for custom functionality that only serves a small subset of our users - custom functionality should be implemented outside of our codebase, via a plugin. From 09d3f5ad6c19b63a06a10a180665a4656c09fdc7 Mon Sep 17 00:00:00 2001 From: Kyle Shockey Date: Mon, 24 Jul 2017 23:31:54 -0700 Subject: [PATCH 2/9] Add Github link --- CONTRIBUTING.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 8ee83573..10decc8f 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -38,14 +38,14 @@ If there's an issue filed that you're addressing in your branch, include the iss - Use the imperative mood in your subject lines, as if you were giving the code an order in your subject line. - This mimics what Git does for you automatically: "Merge develop", "Revert f570ffc", etc - Simple trick... your subject line should complete this sentence: `If applied, this commit will [your subject line].` -- Don't use [magic GitHub words]() in your commits to close issues - do that in the pull request for your code instead. +- Don't use [magic GitHub words](https://help.github.com/articles/closing-issues-using-keywords/) in your commits to close issues - do that in the pull request for your code instead. _Adapted from [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/#seven-rules)._ #### Making pull requests - **Do** summarize your changes in the PR body. If in doubt, write a bullet-point list titled `This PR does the following:`. -- **Do** include references to issues that your PR solves, and use [magic GitHub words]() to close those issues automatically when your PR is merged. +- **Do** include references to issues that your PR solves, and use [magic GitHub words](https://help.github.com/articles/closing-issues-using-keywords/) to close those issues automatically when your PR is merged. - **Do** include tests that cover new or changed functionality. - **Do** be careful to follow our ESLint style rules. We recommend installing an ESLint plugin if you use a graphical code editor. - **Do** make sure that tests and the linter are passing by running `npm test` locally, otherwise we can't merge your pull request. From 962464980f4b59e57956856a8a4d9a2f147b5aba Mon Sep 17 00:00:00 2001 From: Kyle Shockey Date: Mon, 24 Jul 2017 23:34:28 -0700 Subject: [PATCH 3/9] Add information on version branches --- CONTRIBUTING.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 10decc8f..823392ce 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -14,7 +14,9 @@ Feature branches should be prefixed with `ft/`. Bugfix branches should be prefixed with `bug/`. -After the forward slash, include a short description of what you're fixing. For example: `bug/fix-everything-that-was-broken`. +Version branches should be prefixed with `v/`. + +After the forward slash, include a short description of what you're fixing. For example: `bug/fix-everything-that-was-broken`. For versions, add the version that will be released via the branch, for example: `v/1.2.3`. If there's an issue filed that you're addressing in your branch, include the issue number directly after the forward slash. For example: `bug/1234-fix-all-the-other-things`. From 624f491510c321e96f879a273a776b4b0abffe44 Mon Sep 17 00:00:00 2001 From: shockey Date: Mon, 24 Jul 2017 23:39:20 -0700 Subject: [PATCH 4/9] Update CONTRIBUTING.md --- CONTRIBUTING.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 823392ce..6f682ff7 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,5 +1,7 @@ ## Contributing to Swagger-UI +We love contributions from our community of users! This document explains our guidelines and workflows. Please take care to follow them, as it helps us keep things moving smoothly. + #### Environment setup 0. Install Node.js (4 or newer) and npm (3 or newer). From 403598ec7810fef928f213eae67e4a0cb846252c Mon Sep 17 00:00:00 2001 From: shockey Date: Tue, 25 Jul 2017 23:13:44 -0700 Subject: [PATCH 5/9] Update CONTRIBUTING.md --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 6f682ff7..a48d5bf3 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -5,7 +5,7 @@ We love contributions from our community of users! This document explains our gu #### Environment setup 0. Install Node.js (4 or newer) and npm (3 or newer). -1. Fork Swagger-UI, and clone your fork. +1. Make a fork of Swagger-UI on GitHub, then clone your fork to your machine. 2. Run `npm install` in your Swagger-UI directory. 3. Run `npm run dev`. `localhost:3200` should open automatically. 4. You're ready to go! From 5aa7f307bf03ee40fb8c1222fba4eb16a929ef7a Mon Sep 17 00:00:00 2001 From: Minasokoni Date: Wed, 9 Aug 2017 22:47:53 -0700 Subject: [PATCH 6/9] changed radius on input in topbar --- src/style/_topbar.scss | 1 + 1 file changed, 1 insertion(+) diff --git a/src/style/_topbar.scss b/src/style/_topbar.scss index d3b76aa6..4bded694 100644 --- a/src/style/_topbar.scss +++ b/src/style/_topbar.scss @@ -43,6 +43,7 @@ margin: 0; border: 2px solid #547f00; + border-radius: 4px 0 0 4px; outline: none; } From 964d5287351234bd8821e61cea6b82a0140a18bd Mon Sep 17 00:00:00 2001 From: Kyle Shockey Date: Thu, 10 Aug 2017 18:26:45 -0700 Subject: [PATCH 7/9] Replace valueSeq with entrySeq --- src/core/curlify.js | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/core/curlify.js b/src/core/curlify.js index 2564ed92..328830c1 100644 --- a/src/core/curlify.js +++ b/src/core/curlify.js @@ -20,7 +20,7 @@ export default function curl( request ){ if ( request.get("body") ){ if(type === "multipart/form-data" && request.get("method") === "POST") { - for( let [ k,v ] of request.get("body").values()) { + for( let [ k,v ] of request.get("body").entrySeq()) { curlified.push( "-F" ) if (v instanceof win.File) { curlified.push( `"${k}=@${v.name};type=${v.type}"` ) From 168e2030409350463ae1ac504c6bbca59eafe9e0 Mon Sep 17 00:00:00 2001 From: Kyle Shockey Date: Thu, 10 Aug 2017 18:27:03 -0700 Subject: [PATCH 8/9] Use hash for body in formData tests I couldn't find any instances of body being an array when testing formData with real specs... I think this was a mistake. --- test/core/curlify.js | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/test/core/curlify.js b/test/core/curlify.js index 82ee6a8a..8084bd6e 100644 --- a/test/core/curlify.js +++ b/test/core/curlify.js @@ -132,10 +132,10 @@ describe("curlify", function() { url: "http://example.com", method: "POST", headers: { "content-type": "multipart/form-data" }, - body: [ - ["id", "123"], - ["name", "Sahar"] - ] + body: { + id: "123", + name: "Sahar" + } } let curlified = curl(Im.fromJS(req)) @@ -152,10 +152,10 @@ describe("curlify", function() { url: "http://example.com", method: "POST", headers: { "content-type": "multipart/form-data" }, - body: [ - ["id", "123"], - ["file", file] - ] + body: { + id: "123", + file + } } let curlified = curl(Im.fromJS(req)) From eb159232f91a2abcdc96cee639e03cc81a6a427c Mon Sep 17 00:00:00 2001 From: Kyle Date: Thu, 10 Aug 2017 18:42:09 -0700 Subject: [PATCH 9/9] Shorten commiting section --- CONTRIBUTING.md | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index a48d5bf3..3acb80b0 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -36,12 +36,8 @@ If there's an issue filed that you're addressing in your branch, include the iss - Break your commits into logical atomic units. Well-segmented commits make it _much_ easier for others to step through your changes. - Limit your subject (first) line to 50 characters (GitHub truncates more than 70). - Provide a body if you'd like to explain your commit in detail. -- Separate the subject from the body with a blank line, for readability. -- Capitalize the beginning of your subject line. -- Do not end the subject line with a period. -- Use the imperative mood in your subject lines, as if you were giving the code an order in your subject line. - - This mimics what Git does for you automatically: "Merge develop", "Revert f570ffc", etc - - Simple trick... your subject line should complete this sentence: `If applied, this commit will [your subject line].` +- Capitalize the beginning of your subject line, and do not end the subject line with a period. +- Your subject line should complete this sentence: `If applied, this commit will [your subject line].` - Don't use [magic GitHub words](https://help.github.com/articles/closing-issues-using-keywords/) in your commits to close issues - do that in the pull request for your code instead. _Adapted from [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/#seven-rules)._