DOCS GraphQL build requirement changes

docs/en/00_Getting_Started/00_Server_Requirements.md

@@ -106,6 +106,26 @@ app/
 
 Don't forget to include this additional folder in any syncing and backup processes!
 
+### Building, Packaging and Deployment
+
+It is common to build a SilverStripe application into a package on one environment (e.g. a CI server),
+and then deploy the package to a (separate) webserver environment(s).
+This approach relies on all auto-generated files required by SilverStripe to
+be included in the package, or generated on the fly on each webserver environment.
+
+The easiest way to ensure this is to commit auto generated files to source control.
+If those changes are considered too noisy, here's some pointers for auto-generated files
+to trigger and include in a deployment package:
+
+ * `public/_resources/`: Frontend assets copied from the (inaccessible) `vendor/` folder
+   via [silverstripe/vendor-plugin](https://github.com/silverstripe/vendor-plugin).
+   See [Templates: Requirements](/developer_guides/templates/requirements#exposing-assets-webroot).
+ * `.graphql/` and `public/_graphql/`: Schema and type definitions required by CMS and any GraphQL API endpoint. Generated through
+   [silverstripe/graphql v4](https://github.com/silverstripe/silverstripe-graphql).
+   Triggered by `dev/build`, or [GraphQL Schema Build](/developer_guides/graphql/getting_started/building_the_schema).
+ * Various recipes create default files in `app/` and `public/` on `composer install`
+   and `composer update` via
+   [silverstripe/recipe-plugin](https://github.com/silverstripe/recipe-plugin).
 
 ### Web Worker Concurrency
 
@@ -215,7 +235,7 @@ SilverStripe's PHP support has changed over time and if you are looking to upgra
 | 3.6                  | 5.3 - 7.1   | |
 | 3.7                  | 5.3 - 7.3   | [changelog](https://docs.silverstripe.org/en/3/changelogs/3.7.0/) |
 | 4.0 - 4.4            | 5.6+        | |
-| 4.5+ (unreleased)    | 7.1+        | [blog post](https://www.silverstripe.org/blog/our-plan-for-ending-php-5-6-support-in-silverstripe-4/) |
+| 4.5+                 | 7.1+        | [blog post](https://www.silverstripe.org/blog/our-plan-for-ending-php-5-6-support-in-silverstripe-4/) |
 
 
 ## CMS browser requirements

docs/en/02_Developer_Guides/01_Templates/03_Requirements.md

@@ -47,7 +47,7 @@ Files contained inside the `app/client/dist` and `app/images` will be made publi
 
 SilverStripe projects should not track the "resources" directory in their source control system.
 
-### Exposing assets in the web root
+### Exposing assets in the web root {#exposing-assets-webroot}
 
 SilverStripe projects ship with [silverstripe/vendor-plugin](https://github.com/silverstripe/vendor-plugin).
 This Composer plugin automatically tries to expose assets from your project and installed modules after installation, or after an update.

docs/en/02_Developer_Guides/19_GraphQL/01_getting_started/03_building_the_schema.md

@@ -35,11 +35,11 @@ The task that generates the schema code is `build-schema`. It takes a parameter
 
 Keep in mind that many of your changes will be in YAML, which also requires a flush.
 
-`$ vendor/bin/sake dev/graphql/build schema=default flush=1
+`$ vendor/bin/sake dev/graphql/build schema=default flush=1`
 
 [info]
 If you do not provide a `schema` parameter, the task will build all schemas.
-[/info]`
+[/info]
 
 ### Building on dev/build
 
@@ -60,7 +60,7 @@ for initial builds and deployments, but during incremental development this can
 slow things down.
 
 To mitigate this, the generated code for each type is cached against a signature.
-If the type hasn't changed, it doesn't re-render. This reduces build times to **under one second** for incremental changes.
+If the type hasn't changed, it doesn't re-render. This reduces build times to **under one second** for incremental changes. 
 
 #### Clearing the cache
 
@@ -90,6 +90,14 @@ Though it doesn't contain any highly sensitive data, we recommend you block this
 ### Viewing the generated code
 
 By default, the generated code is placed in the `.graphql/` directory in the root of your project.
+It is not meant to be accessible through your webserver (which is ensured by dot-prefixing)
+and keeping it outside of the `public/` webroot. 
+
+Additional files are generated for CMS operation in `public/_graphql/`, and
+those are meant to be accessible through your webserver.
+See [Tips and Tricks: Schema Introspection](tips_and_tricks#schema-introspection)
+to find out how to generate these files for your own schema.
+
 
 ### Further reading
 

docs/en/02_Developer_Guides/19_GraphQL/07_tips_and_tricks.md

@@ -142,12 +142,12 @@ This feature is experimental, and has not been thoroughly evaluated for security
 [/warning]
 
 
-## Schema introspection
+## Schema introspection {#schema-introspection}
 
 Some GraphQL clients such as [Apollo](http://apollographql.com) require some level of introspection
 into the schema. The `SchemaTranscriber` class will persist this data to a static file in an event 
 that is fired on completion of the schema build. This file can then be consumed by a client side library
-like Apollo. The `silverstripe-admin` module is built to consume this data and expects it to be in a
+like Apollo. The `silverstripe/admin` module is built to consume this data and expects it to be in a
 web-accessible location.
 
 
@@ -167,3 +167,18 @@ web-accessible location.
    }
 
 ```
+By default, the file will be stored in `public/_graphql`. Files are only generated for the `silverstripe/admin` module.
+
+If you need these types for your own uses, add a new handler:
+
+```yml
+SilverStripe\Core\Injector\Injector:
+  SilverStripe\EventDispatcher\Dispatch\Dispatcher:
+    properties:
+      handlers:
+        graphqlTranscribe:
+          on: [ graphqlSchemaBuild.mySchema ]
+          handler: '%$SilverStripe\GraphQL\Schema\Services\SchemaTranscribeHandler'
+```
+
+This handler will only apply to events fired in the `mySchema` context.