Resolves: https://github.com/tuist/tuist/issues/887
- Test targets declare their host applications as a dependency
- This lead to a few graph queries transitively including depdencies of the application in the test targets
- When performing dependency searches, we can skip dependency tree of nodes that can embed products (e.g. Applications)
Test Plan:
- Run `tuist generate` within `fixtures/ios_app_with_transitive_framework`
- Open the generated workspace
- Verify that `AppUITests` has no precompiled frameworks included
### Short description 📝
While working on https://github.com/bloomberg/xcdiff/pull/40, we discovered that some of the build files are missing `RemoveHeadersOnCopy` attribute. The attribute determines if the headers should be striped from the archive, and if not set, can lead to headers leakage. The attribute is not visible in the Xcode UI, but added automatically every time a certain bundle types are added to a copy files build phase (i.e. .framework, .appex).
Oddly the attribute is not added for `.xcframework`, but it's probably an Xcode issue (FB7533618).
### Solution 📦
Added "RemoveHeadersOnCopy" attribute for build files in embed precompiled frameworks, embed watch content, and embed app extensions build phases.
### Implementation 👩💻👨💻
- [x] Update TuistGenerator to add `RemoveHeadersOnCopy`
- [x] Update acceptance tests
- [x] Update CHANGELOG
Resolves https://github.com/tuist/tuist/issues/667
### Short description 📝
A follow up to https://github.com/tuist/tuist/pull/730 where workspace schemes are exposed in the `ProjectDescription`. This is the final step of the steps included in the issue.
### Solution 📦
Expose `TargetReference` for both project and workspace schemes. Users can use `.project(path: "sometime/somepath", name: "targetname")` to reference targets within custom workspace schemes.
Due to how the generation process works (especially how `generatedProjects` are populated in the `ProjectGenerator`), `.project(path: .., name: ..)` we cannot reference remote targets in project schemes yet without some changes in the `ProjectGenerator`. This is not a problem for workspace schemes. Since the `ProjectDescription` `Scheme` is shared by both workspaces and projects, I've added a scheme linting rule to check that targets defined in custom project schemes are within the current project i.e., not referencing remote targets in other projects.
### Implementation 👩💻👨💻
- [X] Update `ProjectDescription` to support `TargetReference`
- [X] Add Project scheme linter for the referencing remote targets invalid case
- [X] Update fixture `ios_app_with_custom_scheme` to add workspace scheme
* Support importing helper files from the manifest that are defined in the TuistConfig/ProjectDescriptionHelpers directory
* Remove TuistDirectoryLocator
* Generate a more complet project
* Add acceptance tests
* Test ProjectDescriptionHelpersBuilder
* Use derived Info.plist files instead
* Address some comments
### Short description
Adds support for watchOS apps.
### Solution
Add support for watchOS / watchOS Extension products as well as the appropriate dependency rules.
### Implementation
- [x] Add product types
- [x] Add fixture & acceptance test
- [x] Update graph / link rules
- [x] Add embed watch build phase
- [x] Add watch build settings
- [x] Add linter rules for bundle IDs
- [x] Add linter rules for valid product types
- [x] Update changelog
- [x] Update documentation
### Test Plan
- Run `tuist generate` within `fixtures/ios_app_with_watchapp2`
- Verify the generated project contains a Watch App & Watch App Extension
- Compare against a manually created project with a Watch App
* Delete embed logic
* Add methods to read the dsym path & bcsymbolmap paths from a framework
* Place the tests in the right test case
* Implement EmbedScriptGenerator
* Test EmbedScriptGenerator
* Extract methods that interact with the system into metadata provider utilities and fix tests
* Include output paths
* Test FrameworkMetadataProvider
* Test PrecompiledMetadataProvider
* Add more tests
* Create fixture project
* Add acceptance test
* Address comments
* Use Xcode 11.1
* Update Package.resolved
* Update XcodeProj
* Make the tuistenv install test more resilient
* Fix build phases not being generated in the right positions
* Remove extra space
* Add CHANGELOG entry
* Fix step
* Fix tests
* Address comments
* Add missing line
Part of https://github.com/tuist/tuist/issues/290
- Tuist support iOS resouce bundles
- This can now be leveraged via specifying `.bundle` product types
- Fixture has been updated to show case how this can be used
Test Plan:
- Run `tuist generate` within `fixtures/ios_app_with_framework_and_resources`
- Verify the project `StaticFramework` has a bundle target called `StaticFrameworkResources` which includes resources
- Verify the `StaticFrameworkResources` bundle is copied as a resouce in the App
- Verify running the app prints out descriptions for images within `StaticFrameworkResources`
* Add model changes to ProjectDescription
* Add models to the TuistGenerator target
* Create Xcode & XcodeController to interact with local Xcode installations
* Implement TuistConfigLinter
* Add acceptance test
* Support initializing CompatibleXcodeVersions with a string literal
* Add documentation
* Update CHANGELOG
* Address comments
* Fix imports
* Rename TuistConfigLinter to EnvironmentLinter
* Some style fixes
* Add TargetDependency.cocoapods
* Add Dependency.cocoapods
* Add CocoaPodsNode model and support for caching it to the GraphLoaderCache
* Add tests to CocoaPodsNode
* Support loading a CocoaPods target dependency
* Test TargetNode changes
* Lint that the directories referenced by CocoaPods dependencies contain a Podfile
* Run 'pod install' after the workspace generation
* Add documentation
* Update Pod specs repository automtically
* Update CHANGELOG
* Add acceptance tests
* Remove empty code block and fix acceptance test
Pedro Piñera