SWIFT-1437: Update Development Guide and Linting (#719)

Author: nspektor

Guides/Development.md

@@ -31,14 +31,7 @@ Run `swift build` or simply `make` in the project's root directory.
 If you add symbols you may need to run `make exports` which will generate [Sources/MongoSwiftSync/Exports.swift](Sources/MongoSwiftSync/Exports.swift). This makes symbols declared in `MongoSwift` available to importers of `MongoSwiftSync`.
 
 ### In Xcode
-We do not provide or maintain an already-generated `.xcodeproj` in our repository. Instead, you must generate it locally.
-
-**To generate the `.xcodeproj` file**:
-1. Install the Ruby gem `xcodeproj` with `gem install xcodeproj` (you may need to `sudo`)
-2. Run `make project`
-3. You're ready to go! Open `MongoSwift.xcodeproj` and build and test as normal.
-
-Why is this necessary? The project requires a customized "copy resources" build phase to include various test `.json` files. By default, this phase is not included when you run `swift package generate-xcodeproj`. So `make project` first generates the project, and then uses `xcodeproj` to manually add the files to the appropriate targets (see `add_json_files.rb`).
+From the driver root directory, you can run `xed .` to open the project in xcode and be able to build and run there. 
 
 ## Running Tests
 **NOTE**: Several of the tests require a mongod instance to be running on the default host/port, `localhost:27017`. You can start this by running `mongod --setParameter enableTestCommands=1`. The `enableTestCommands` parameter is required to use some test-only commands built into MongoDB that we utilize in our tests, e.g. `failCommand`.
@@ -76,12 +69,14 @@ Our documentation site is automatically generated from the source code using [Ja
 If you'd like to preview how new documentation you've written will look when published, you can regenerate it by running `./etc/generate-docs.sh` and then inspecting the generated HTML files in `/docs`.
 
 ## Linting and Style
-We use [SwiftLint](https://github.com/realm/SwiftLint#using-homebrew) for linting. You can see our configuration in the `.swiftlint.yml` file in the project's root directory.  Run `swiftlint` in the root directory to lint all of our files. Running `swiftlint autocorrect` will correct some types of violations.
+We use [SwiftLint](https://github.com/realm/SwiftLint#using-homebrew) for linting. You can see our configuration in the `.swiftlint.yml` file in the project's root directory.  Run `swiftlint` in the root directory to lint all of our files. Running `swiftlint --fix` will correct some types of violations.
 
 We use [SwiftFormat](https://github.com/nicklockwood/SwiftFormat) for formatting the code. You can see our configuration in the `.swiftformat` file in the project's root directory. Our linter config contains a superset of the rules that our formatter does, so some manual tweaking may be necessary to satisfy both once the formatter is run (e.g. line length enforcement). Most of the time, the formatter should put the code into a format that passes the linter. You can run the formatter on all of the files by running `swiftformat .` from the root directory.
 
 To pass all the formatting stages of our testing matrix, both `swiftlint --strict` and `swiftformat --lint .` must finish successfully.
 
+`make lint-and-format` runs `swiftlint --fix`, `swiftlint --strict` and `swiftformat --lint .`.
+
 For style guidance, look at Swift's [API design guidelines](https://swift.org/documentation/api-design-guidelines/) and Google's [Swift Style Guide](https://google.github.io/swift/).
 
 ## Editor Setup
@@ -116,11 +111,8 @@ If you have a setup for developing the driver in an editor other than the ones l
 ## Workflow
 1. Create a feature branch, named by the corresponding JIRA ticket if exists, along with a short descriptor of the work: for example, `SWIFT-30/writeconcern`.
 1. Do your work on the branch.
-1. If you add, remove, or rename any tests, make sure to update `LinuxMain.swift` accordingly. If you are on MacOS, you can do that by running `make linuxmain`.
 1. Ensure your code passes both the linter and the formatter.
-1. Make sure your code builds and passes all tests on:
-    - [Travis](https://travis-ci.org/mongodb/mongo-swift-driver). Every time you push to GitHub or open a pull request, it will trigger a new build, which includes running the linter, formatter, and basic tests.
-    - (If you work at MongoDB) [Evergreen](https://evergreen.mongodb.com/waterfall/mongo-swift-driver) - Our Evergreen matrix tests a variety of MongoDB configurations, operating systems, and Swift language versions, and provides a way to more robustly test the driver. A new Evergreen build is automatically triggered for every commit to `main`, but for more complex pull requests it's a good idea to run patches on Evergreen before merging.
+1. Make sure your code builds and passes all tests on [Evergreen](https://evergreen.mongodb.com/waterfall/mongo-swift-driver). Our Evergreen matrix tests a variety of MongoDB configurations, operating systems, and Swift language versions, and provides a way to more robustly test the driver. If you work at MongoDB, a new Evergreen build is automatically triggered for every commit to `main` and for every pull request. If you do not work at MongoDB, ask a maintainer to trigger a test run on evergreen for you.
 1. Open a pull request on the repository. Make sure you have rebased your branch onto the latest commits on `main`.
 1. Go through code review to get the team's approval on your changes. (See the next section on [Code Review](#code-review) for more details on this process.) Once you get the required approvals and your code passes all tests:
 1. Rebase on `main` again if needed.

Makefile

@@ -26,9 +26,14 @@ test-pretty:
 	set -o pipefail && swift test $(FILTERARG) 2>&1 | xcpretty
 
 lint:
-	swiftlint autocorrect
+	swiftlint --fix
 	swiftlint
 
+lint-and-format:
+	swiftlint --fix
+	swiftlint --strict --quiet
+	swiftformat --lint .
+
 # MacOS only
 coverage:
 	swift test --enable-code-coverage