Merge pull request #730 from bgarret/patch-1

Update CONTRIBUTING.md

CONTRIBUTING.md

@@ -5,8 +5,9 @@ Contributing
 * [Pull Requests](#pull-requests)
 * [Testing](#testing)
 * [SDK Design](#sdk-design)
-    * [Downloading schemas](#downloading-schemas-schemadownload)
-    * [Refactoring schemas](#refactoring-schemas-schemarefactor)
+    * [Downloading schemas](#downloading-schemas-php-binconsole-schemadownload)
+    * [Refactoring schemas](#refactoring-schemas-php-binconsole-schemarefactor)
+    * [Generating code](#generating-code-php-binconsole-schemagenerate)
     * [Generator control files](#generator-control-files)
 
 We welcome any and all contributions! There are a few ways you can contribute to this project:
@@ -38,7 +39,7 @@ You can run the tests with `composer test`. We're using PHPUnit under the hood.
 
 ## SDK Design
 
-This SDK is (almost) entirely autogenerated from Amazon's OpenAPI model files, using [highsidelabs/saloon-sdk-autogenerator](https://github.com/highsidelabs/saloon-sdk-autogenerator). As with most big multi-file OpenAPI specifications, the Selling Partner API spec took quite a bit of massaging to get into a format that worked well with an autogenerator. A lot of work was put into making sure that the generation process, from downloading the model files to the generated code, is idempotent and reliable.
+This SDK is (almost) entirely autogenerated from Amazon's OpenAPI model files, using [highsidelabs/saloon-sdk-generator](https://github.com/highsidelabs/saloon-sdk-generator). As with most big multi-file OpenAPI specifications, the Selling Partner API spec took quite a bit of massaging to get into a format that worked well with an autogenerator. A lot of work was put into making sure that the generation process, from downloading the model files to the generated code, is idempotent and reliable.
 
 There are three major steps to building this library:
 
@@ -69,11 +70,11 @@ Downloaded OpenAPI models are placed in `resources/models/raw/<category>/<api-na
 
 A wide variety of refactoring processes are run on the raw schemas to get them ready to be used in the following step: code generation. The refactoring process code is in `SchemaVersion::refactor()`.
 
-Certain schema changes need to be made manually, because they are too specific or too cumbersome to make in the code. These modifications are defined in the `resources/modifications.json` file, which is explained more thoroughly [below](#modificationsjson).
+Certain schema changes need to be made manually, because they are too specific or too cumbersome to make in the code. These modifications are defined in the [resources/metadata/modifications.json](https://github.com/highsidelabs/saloon-sdk-generator/tree/master/src/resources/metadata/modifications.json) file, which is explained more thoroughly [below](#modificationsjson).
 
 Once refactoring is complete, the finalized OpenAPI model file is saved to `resources/models/<category>/<api-name>/<version>.json`. These files _are_ version-controlled, unlike the raw models, because having them available to everyone makes it easier to reason about the autogeneration process.
 
-### Generating code
+### Generating code: `php bin/console schema:generate`
 
 Finally, the code is generated from the finalized OpenAPI models. We use `highsidelabs/saloon-sdk-generator` for this, which handles most of the heavy lifting. All the files in the `SellingPartnerApi\Seller` and `SellingPartnerApi\Vendor` namespaces (and some other files) are autogenerated, so _do not_ edit any of that code directly! Any changes to those files will be overridden the next time the library is generated, so if you want to make a change to any of that code, that change will have to be made by either a) modifying/extending the generator code, or b) via the [`modifications.json`](#modificationsjson) file. Files that are autogenerated have warning comments at the top of the file to indicate that they should not be edited manually.