* Update the Graph linter to use the value graph model instead
* Fix test
* Precompile framework
* Fix Swiftlint issue
* Some style fixes
* Pass macOS deployment target
* Fix acceptance tests
* Fix "Embed Frameworks" build phase parameters
Resolves: https://github.com/tuist/tuist/issues/2153
- Generated projects had a missing empty `dstPath` parameter for the "Embed Frameowkrs" build phase
- This was discovered while comparing projects where the same phase was added by Xcode (via the UI when embedding frameworks)
- This small mismatch in parmeters results in build failures when linking against Swift Package binary dependencies
- Adding a new fixture that depends on a binary dependency (FirebaseAnalytics)
Test Plan:
- Run `swift build && swift run tuist generate --path fixtures/ios_app_with_remote_binary_swift_package`
- Verify the generated project builds
* Switch fixture to local package with binary target
* Update change log
* Add Playground sources as playgrounds
* Update CHANGELOG
* Update documentation
* Make regex more generic and revert Package.resolved changes
* Address comments
* Filter out the playgrounds from the resources too
* Fix linting issues
* Set the riht xcLanguageSpecificationIdentifier attribute to playgrounds
* Fix default generated scheme arguments
- Default profile scheme actions were manually inheriting the run action arguments
- There is a built in mechanism for doing so in Xcode alleviating the need to manually copy them across
- The default run action arguments were always specified even when empty, this produces a scheme with empty list of arguments (which is different from no arguments)
Test Plan:
- Run `swift build && swift run tuist generate --path fixtures/ios_app_with_tests`
- Inspect the generated Project schemes
- Verify the profile action for App has the "Use the Run action's arguments and environment" checked
- Verify the raw `.xcscheme` doesn't contain any commandline arguments nor environment variable entries
* Update changelog
* Missing required module 'XXX' when running unit tests with cached dependencies
* Gather precompiled libraries and frameworks by reusing optimised graph traversing method
* Fix formatting
* Fix formatting
* Add an acceptance test ios_app_with_transitive_project
* Restore 'recursivePrecompiledDependencies' implementation
* Add unit tests to a Graph for linkable and embeddable dependencies (warning: some tests are failing)
* Fix an order of the check for linkable assertion in GraphTests unit test
* Fix the unit tests
* Add more linkableDependencies unit tests
* Add unit tests to ValueGraphTraverser (warning: one test is failing)
* Fix linting and unit tests
* Add more unit tests
* Update unit tests
* Improve comparing the results in unit tests
* Fix formatting
* Add a changelog entry
* Update generators to use the traverser
* Update CHANGELOG
* Fix tests
* Add few missing sorts
* Fix an issue that resulted in not all the nodes being traversed through
- The equivalent method of `directTargetDependencies` in the reference Graph used to return local targets only
- Updated the value graph traverser to behave in a similar fashion
- Updated unit tests to include a scenario that could catch this
- **Note:** This fixes an issue that previously allowed extension targets to be defined in a separate project (which isn't a supported dependency type)
Test Plan:
- Verify unit tests pass
Resolves: https://github.com/tuist/tuist/issues/1937
- System & Developer SDK nodes were accidentally swaped in the graph loading logic
- `.xctest` is a developer SDK vs others are system
- System SDKs do not require any special additional framework search paths as such this has now been removed
Test Plan:
- Run `swift build && swift run tuist generate --path fixtures/ios_app_with_sdk`
- Inspect the generated project
- Verify framework search paths are not added for system SDKs
- Verify `MyTestFramework` continues to build successfully
Resolves [no ticket]
### Short description 📝
Code coverage is not enabled when schemes are automatically generated. To enable it, one needs to define a scheme manually to enable `Coverage` and set `codeCoverageTargets`.
This change introduces a new `generationOption` case: `enableCodeCoverage` that will enable code coverage for automatically generated schemes.
### Solution 📦
I started by attempting to update Project.swift with a manually-defined scheme to enable code coverage, but there are a lot of projects in our workspace and it seemed like a broader solution would be more useful than one that would require touching each project (and potentially ensuring the stand-in schemes are kept up-to-date).
I started with my colleague @kalkwarf's PR #1782 and used that as a guide to make similar changes in what seemed like appropriate places including the generator code, tests, and documentation.
This change doesn't introduce any breaking changes and hopefully avoids any unnecessary complexity, while making it possible to enable code coverage with one line:
```
let config = Config(
generationOptions: [
// your options here
.enableCodeCoverage, <-- this one :-)
]
)
```
### Implementation 👩💻👨💻
- [x] Extend `GenerationOptions` enum with `enableCodeCoverage` case.
- [x] Update `AutogeneratedSchemesProjectMapper` to initialize with `TuistCore.Config` .
- [x] Check config to to enable code coverage and generate code coverage targets.
- [x] Update `AutogeneratedSchemesProjectMapperTests` to verify new behavior.
- [x] Checked that existing tests would fail if the they were run with the new option.
- [x] Added new case to `docs/usage/config.mdx`.
### **One more thing™**
~This is a draft since I am not sure the test configuration this produces is correct, but I wanted to get eyes on the changes to the project in general.~ Looks like the coverage config is good to go! Thanks for reading!!
Pedro Piñera Buendía