Extract Prettier config into prettierrc (ory#160)

Author: Kevin Goslar

.prettierrc

@@ -0,0 +1,5 @@
+{
+  "proseWrap": "always",
+  "singleQuote": true,
+  "trailingComma": "es5"
+}

docs/ecosystem/cloud-native.md

@@ -8,9 +8,9 @@ All ORY technology is built cloud native and follows
 
 ## 12 Factor Concepts
 
-The following is a collection of core concepts to ORY's technological philosophy.
-They are summaries of the [12factor principles](https://www.12factor.net)
-written by Adam Wiggins.
+The following is a collection of core concepts to ORY's technological
+philosophy. They are summaries of the
+[12factor principles](https://www.12factor.net) written by Adam Wiggins.
 
 ### Codebase: One codebase tracked in revision control, many deploys
 

docs/ecosystem/versioning.md

@@ -16,21 +16,21 @@ service versions and what they mean.
 
 There are three maturity levels for services:
 
-- **Graduated services** are mature, stable implementations of proven concepts. 
-  They rarely change in backwards incompatible ways. A
-  service is considered graduated if the major version is >= 1, e.g. `v1.0.1`, `v2.2.2`. 
-  Backwards incompatible changes are indicated by a bump of the major version number. 
-  Most, if not all, REST APIs will provide
-  backwards compatible transformations that make it possible to interact with
-  the server using older API versions.
-- **Incubating services** implement well defined but not fully matured concepts. 
-  Incubating services have a major
-  version number of `0`, e.g. `v0.10.0`. They have a higher (but overall moderate) probability for
-  larger changes that can break backwards compatibility, for which there are upgrade guides.
-- **Sandbox services** implement concepts, APIs and CLIs at the experimental stage and can change in
-  unpredictable ways. These services have a major version number of
-  `0` and the `sandbox` label, e.g. `v0.10.0-sandbox`. We will provide
-  upgrade guides wherever possible, especially when they are used in production already.
+- **Graduated services** are mature, stable implementations of proven concepts.
+  They rarely change in backwards incompatible ways. A service is considered
+  graduated if the major version is >= 1, e.g. `v1.0.1`, `v2.2.2`. Backwards
+  incompatible changes are indicated by a bump of the major version number.
+  Most, if not all, REST APIs will provide backwards compatible transformations
+  that make it possible to interact with the server using older API versions.
+- **Incubating services** implement well defined but not fully matured concepts.
+  Incubating services have a major version number of `0`, e.g. `v0.10.0`. They
+  have a higher (but overall moderate) probability for larger changes that can
+  break backwards compatibility, for which there are upgrade guides.
+- **Sandbox services** implement concepts, APIs and CLIs at the experimental
+  stage and can change in unpredictable ways. These services have a major
+  version number of `0` and the `sandbox` label, e.g. `v0.10.0-sandbox`. We will
+  provide upgrade guides wherever possible, especially when they are used in
+  production already.
 
 To make deployment easier but stay compatible with semantic versioning, each
 service is equipped with a `oryOS` version number denoted by `+oryOS.X` where

docs/hydra/configuration.md

@@ -1,9 +1,9 @@
----
-id: configuration
-title: Configuration
----
-
-```yaml
+---
+id: configuration
+title: Configuration
+---
+
+```yaml
 # ORY Hydra Configuration
 #
 #
@@ -190,7 +190,6 @@ serve:
       # If set to true, adds additional log output to debug server side CORS issues. Defaults to false.
       debug: true
 
-
   # tls configures HTTPS (HTTP over TLS). If configured, the server automatically supports HTTP/2.
   tls:
     # key configures the private key (pem encoded)
@@ -294,7 +293,6 @@ oidc:
 
   # dynamic_client_registration configures OpenID Connect Dynamic Client Registration (exposed as admin endpoints /clients/...)
   dynamic_client_registration:
-
     # The OpenID Connect Dynamic Client Registration specification has no concept of whitelisting OAuth 2.0 Scope. If you
     # want to expose Dynamic Client Registration, you should set the default scope enabled for newly registered clients.
     # Keep in mind that users can overwrite this default by setting the "scope" key in the registration payload,
@@ -306,7 +304,6 @@ oidc:
 
 urls:
   self:
-
     # This value will be used as the "issuer" in access and ID tokens. It must be
     # specified and using HTTPS protocol, unless --dangerous-force-http is set. This should typically be equal
     # to the public value.
@@ -386,7 +383,6 @@ secrets:
     - this-is-an-old-secret
     - this-is-another-old-secret
 
-
 # Enables profiling if set. Use "cpu" to enable cpu profiling and "mem" to enable memory profiling. For more details
 # on profiling, head over to: https://blog.golang.org/profiling-go-programs
 profiling: cpu
@@ -418,5 +414,4 @@ tracing:
         value: 1.0
         # The address of jaeger-agent's HTTP sampling server
         server_url: http://localhost:5778/sampling
-```
-
+```

docs/hydra/oauth2.md

@@ -550,7 +550,7 @@ logout provider fetches information about the logout request:
 challenge = req.url.query.logout_challenge;
 
 fetch(
-  "https://hydra/oauth2/auth/requests/logout?" +
+  'https://hydra/oauth2/auth/requests/logout?' +
     querystring.stringify({ logout_challenge: challenge })
 )
   .then(function(response) {
@@ -588,10 +588,10 @@ completed as follows:
 
 ```node
 fetch(
-  "https://hydra/oauth2/auth/requests/logout/accept?" +
+  'https://hydra/oauth2/auth/requests/logout/accept?' +
     querystring.stringify({ logout_challenge: challenge }),
   {
-    method: "PUT"
+    method: 'PUT',
   }
 )
   .then(function(response) {
@@ -607,10 +607,10 @@ You can also reject a logout request (e.g. if the user chose to not log out):
 
 ```node
 fetch(
-  "https://hydra/oauth2/auth/requests/logout/reject?" +
+  'https://hydra/oauth2/auth/requests/logout/reject?' +
     querystring.stringify({ logout_challenge: challenge }),
   {
-    method: "PUT"
+    method: 'PUT',
   }
 ).then(function(response) {
   // Now you can do whatever you want - redirect the user back to your home page or whatever comes to mind.

docs/hydra/sdk/js.md

@@ -18,10 +18,10 @@ npm install --save ory-hydra-sdk
 #### Basic configuration
 
 ```js
-const Hydra = require("ory-hydra-sdk");
+const Hydra = require('ory-hydra-sdk');
 
 // Set this to Hydra's URL
-Hydra.ApiClient.instance.basePath = "http://localhost:4445";
+Hydra.ApiClient.instance.basePath = 'http://localhost:4445';
 ```
 
 ### API Usage
@@ -37,9 +37,9 @@ hydra.listOAuth2Clients((error, data, response) => {
   } else if (response.statusCode < 200 || response.statusCode >= 400) {
     // an application error occurred.
     throw new Error(
-      "Consent endpoint gave status code " +
+      'Consent endpoint gave status code ' +
         response.statusCode +
-        ", but status code 200 was expected."
+        ', but status code 200 was expected.'
     );
   }
 

docs/performance/hydra.md

@@ -3,27 +3,35 @@ id: hydra
 title: ORY Hydra
 ---
 
-In this document you will find benchmark results for different endpoints of ORY Hydra. All benchmarks are executed
-using [rakyll/hey](https://github.com/rakyll/hey). Please note that these benchmarks run against the in-memory storage
-adapter of ORY Hydra. These benchmarks represent what performance you would get with a zero-overhead database implementation.
-
-We do not include benchmarks against databases (e.g. MySQL, PostgreSQL or CockroachDB) as the performance greatly differs between
-deployments (e.g. request latency, database configuration) and tweaking individual things may greatly improve performance.
-We believe, for that reason, that benchmark results for these database adapters are difficult to generalize and potentially
+In this document you will find benchmark results for different endpoints of ORY
+Hydra. All benchmarks are executed using
+[rakyll/hey](https://github.com/rakyll/hey). Please note that these benchmarks
+run against the in-memory storage adapter of ORY Hydra. These benchmarks
+represent what performance you would get with a zero-overhead database
+implementation.
+
+We do not include benchmarks against databases (e.g. MySQL, PostgreSQL or
+CockroachDB) as the performance greatly differs between deployments (e.g.
+request latency, database configuration) and tweaking individual things may
+greatly improve performance. We believe, for that reason, that benchmark results
+for these database adapters are difficult to generalize and potentially
 deceiving. They are thus not included.
 
-This file is updated on every push to master. It thus represents the benchmark data for the latest version.
+This file is updated on every push to master. It thus represents the benchmark
+data for the latest version.
 
-All benchmarks run 10.000 requests in total, with 100 concurrent requests. All benchmarks run on Circle-CI with a
+All benchmarks run 10.000 requests in total, with 100 concurrent requests. All
+benchmarks run on Circle-CI with a
 ["2 CPU cores and 4GB RAM"](https://support.circleci.com/hc/en-us/articles/360000489307-Why-do-my-tests-take-longer-to-run-on-CircleCI-than-locally-)
 configuration.
 
 ## BCrypt
 
-ORY Hydra uses BCrypt to obfuscate secrets of OAuth 2.0 Clients. When using flows such as the OAuth 2.0 Client Credentials
-Grant, ORY Hydra validates the client credentials using BCrypt which causes (by design) CPU load. CPU load and performance
-depend on the BCrypt cost which can be set using the environment variable `BCRYPT_COST`. For these benchmarks,
-we have set `BCRYPT_COST=8`.
+ORY Hydra uses BCrypt to obfuscate secrets of OAuth 2.0 Clients. When using
+flows such as the OAuth 2.0 Client Credentials Grant, ORY Hydra validates the
+client credentials using BCrypt which causes (by design) CPU load. CPU load and
+performance depend on the BCrypt cost which can be set using the environment
+variable `BCRYPT_COST`. For these benchmarks, we have set `BCRYPT_COST=8`.
 
 ## OAuth 2.0
 
@@ -39,7 +47,7 @@ Summary:
   Fastest:	0.0003 secs
   Average:	0.0220 secs
   Requests/sec:	4265.3079
-  
+
   Total data:	1550000 bytes
   Size/request:	155 bytes
 
@@ -92,7 +100,7 @@ Summary:
   Fastest:	0.0171 secs
   Average:	0.1901 secs
   Requests/sec:	501.9053
-  
+
   Total data:	1570000 bytes
   Size/request:	157 bytes
 
@@ -137,8 +145,9 @@ Status code distribution:
 
 ### Creating OAuth 2.0 Clients
 
-This endpoint uses [BCrypt](#bcrypt) and generates IDs and secrets by reading from  which negatively impacts
-performance. Performance will be better if IDs and secrets are set in the request as opposed to generated by ORY Hydra.
+This endpoint uses [BCrypt](#bcrypt) and generates IDs and secrets by reading
+from which negatively impacts performance. Performance will be better if IDs and
+secrets are set in the request as opposed to generated by ORY Hydra.
 
 ```
 This test is currently disabled due to issues with /dev/urandom being inaccessible in the CI.
@@ -154,7 +163,7 @@ Summary:
   Fastest:	0.0001 secs
   Average:	0.0037 secs
   Requests/sec:	24815.7713
-  
+
   Total data:	4820000 bytes
   Size/request:	482 bytes
 
@@ -205,7 +214,7 @@ Summary:
   Fastest:	0.0001 secs
   Average:	0.0035 secs
   Requests/sec:	26457.0881
-  
+
   Total data:	4800000 bytes
   Size/request:	480 bytes
 

website/package.json

@@ -13,8 +13,8 @@
     "rename-version": "docusaurus-rename-version",
     "api": "npm-run-all swagger:generate:* swagger:cleanup:*",
     "serve": "serve -p 9009 ./build",
-    "format:markdown": "prettier --write --print-width 80 --prose-wrap always \"{../docs/**,..}/*.md\"",
-    "format:code": "prettier --single-quote --trailing-comma es5 --write \"./**/*.{js,css,html}\"",
+    "format:markdown": "prettier --write \"{../docs/**,..}/*.md\"",
+    "format:code": "prettier --write \"./**/*.{js,css,html}\"",
     "format:json": "prettier --write '../**/*.json' '!../_legacy/**'",
     "format": "npm-run-all -p format:*",
     "swagger:generate:hydra": "widdershins -u ../.widdershins/templates -e ../.widdershins/config.json ../apis/hydra.json -o ../docs/hydra/sdk/api.md",