Resolves https://github.com/tuist/tuist/issues/454
- All `FrameworkNodes` (i.e. prebuilt frameworks) were being embedded regardless of their linkage
- This check was redundant as there was a more general check for `PrecompiledNode` which happens to be the super class of `FrameworkNode` which took into account the framework linkage
- To resolve this issue it was suffice to remove the redundant check
Test Plan:
- Generate `fixtures/ios_app_with_static_frameworks` via running `tuist generate`
- Verify the generated project doesn't embed `PrebuiltStaticFramework`
- Verify the generated project builds successfully
* Implement Context and update usages of the printer to use it through Context.shared
* Fix tests
* Add XCTAssertPrinterError and XCTAssertPrinterError
* Rename the XCT methods
* Simplify API
* Get rid of Context and provide a mockEnvironment() helper method
* Fix linting issues
Resolves https://github.com/tuist/tuist/issues/455
### Short description 📝
> When a static dependency has a dynamic dependencies, those dynamic dependencies need to be linked at the point the static dependency is linked.
This PR fixes the issue where a static dependency's dynamic libraries were linking incorrectly.
### Solution 📦
As we already traverse the graph for static dependencies, we can add a step to this process to check each static dependency's `targetDependencies` for dynamic libraries and add them as a reference adjacent to where the original static dependency is referenced.
### Implementation 👩💻👨💻
- [X] Update `linkableDependencies` in `Graph.swift` to reference a static dependency's dynamic libraries
- [X] Update `GraphTests` to check the test case:
- A (App) -> B (Static) -> C (Dynamic)
- Expected: A -> C
- [X] Update `GraphTests` to check the test case:
- A (App) -> B (Dynamic) -> C (Static) -> D (Static) -> E (Dynamic)
- Expected: A -> B
- Expected: B -> (C, D, E)
- [X] Update `GraphTests` to check the test case:
- A (App) -> B (Dynamic) -> C (Dynamic) -> D (Static) -> E (Static) -> F (Dynamic)
- Expected: B -> C
### Test Plan
- Run `tuist generate` inside `fixtures/ios_app_with_static_frameworks`
- Check that the `App` target has `D` inside `Build Phases -> Link Binary With Libraries`
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`
Resolves https://github.com/tuist/tuist/issues/424
- Localized file extensions are used to determine the `lastKnownFileType`
Test Plan:
- Run `tuist generate` within `fixtures/ios_app_with_framework_and_resources`
- Verify the `lastKnownFileType` of the strings files are set (inspect `App/MainApp.xcodeproj/project.pbxproj`)
* 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
* using custom file name
* swiftformat
* use file name from model
* changelog
* fix test
* enum suffix, prefix, test, and new fixture
* acceptance test
* swiftformat
* new api
* docs and clean ups
* swiftformat and clean up
* expose less at generator level, tuist config tests for code coverage
* more code coverage?
* clean ups
* clean ups
* pr suggestions
* swift format
* fixes tests from changes in master
* 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
Resolves https://github.com/tuist/tuist/issues/467
- All projects' build configurations are now validated against the top level projects
- In the event any are missing or are mismatching (e.g. have a mismatching variant) the linter will now flag them
Example:
```
$ tuist generate
The following issues have been found:
- The project 'Framework2' has missing or mismatching configurations. It has [Debug (debug), Release (release)], other projects have [Beta (release), Debug (debug), Release (release)].
```
Test Plan:
- Run `tuist generate` within `fixtures/ios_app_with_multi_configs`
- Comment out any of the build configurations defined in `App`, `Framework1` or `Framework2`
- Re-run `tuist generate`
- Verify a lint warning is displayed
- Exposing a new `CustomConfiguration` type to allow specifying named configurations with a variant (debug or release) to inner the default settings.
- Adding fixture `fixtures/ios_app_with_multi_configs` with acceptance tests
- Adding additional linting to ensure scheme specified configurations exist
- Updating scheme API to use configuration name strings instead of `BuildConfiguration` enum
- Renamed the `BuildConfiguration` enum to `PresetBuildConfiguration` enum to ensure schemes are backwards compatible
- Updating how default build configurations for scheme targets are selected
- 'Debug' configuration is used for Run, Test and Analyze actions
- 'Release' configuration is used for the Profile & Archive actions.
- If those aren't found, the first alphabetically ordered configuration with the corresponding variant is used
- Adding manifest linter to help flag manifest issues such as duplicate custom configuration names
- Updating documentation to include information on multiple configurations and some of the gotchas to watch out for
Test Plan:
- Run `tuist generate` within `fixtures/ios_app_with_multi_configs`
- Verify the generated project contains the build configurations "Debug", "Beta" and "Release"
- Verify the generated project `Framework2` has a target xcconfig override for the Beta configuration that points to `Target.Beta.xcconfig`
- Verify the generated project has a scheme "App-Beta" which uses the "Beta" configuration when performing the run action
- Verify that referencing a configuration within the scheme that isn't defined in the project flags a listing error
Resolves https://github.com/tuist/tuist/issues/354
### Short description 📝
Add support to specify array of paths / glob patterns for headers such as the case below:
```
Headers(public: ["Sources/A/**/*.h", "Sources/B/**/*.h"],
private: ["Sources/C/**/*.h", "Sources/D/**/*.h"],
project: "Sources/E/**/*.h")
```
### Solution 📦
Similar to the way multiple source file paths/glob patterns were implemented (https://github.com/tuist/tuist/pull/266). We can use `FileList` and `ExpressibleByStringLiteral` to expose public, private and project headers as either a String or Array of Strings. The original `FileList` used for sources was not reused as it contained `compilerFlags` which is specific to source files. A new `FileList` containing only paths/glob patterns was created for use with headers. This way `FileList` can be potentially reused elsewhere.
### Implementation 👩💻👨💻
- [X] Remove `FileList` type alias from `SourceFilesList` and references to it
- [X] Create new `FileList` without `compilerFlags`
- [X] Modify `Headers` to use the new `FileList` for public, private and project headers
- [X] Add tests to `GeneratorModelLoaderTests` to verify newly supported cases work
- [X] Create `ios_app_with_headers` fixture to support new array of strings case for headers
- [X] Write test that verifies `ios_app_with_headers` fixture targets build
### Test Plan
- Run `tuist generate` inside the `ios_app_with_headers` fixture
- Verify that the Framework1 target has the correct header files specified in the manifest
Resolves https://github.com/tuist/tuist/issues/452
### Short description
To support workflows where only the local project needs to be re-generated without re-generating all its dependencies a new generation option is needed (see https://github.com/tuist/tuist/issues/452 for full rationale)
### Solution
Add a new option to generate the local project only.
usage:
```bash
tuist generate --project-only
```
### Implementation
- [x] Expose new generator method that generates a single project
- [x] Expose new option via command line argument `--project-only`
- [x] Update documentation
- [x] Update changelog
### Test Plan
- Run `tuist generate` within `fixtures/ios_app_with_custom_workspace`
- Verify the workspace is still generated with all the dependencies as before
- Run `tuist generate` within `fixtures/ios_app_with_custom_workspace/App`
- Verify the project workspace is still generated with all the dependencies as before
- Run `tuist generate --project-only` within `fixtures/ios_app_with_custom_workspace/App`
- Verify only the `App`'s project re-generated (this can be done by either doing a git clean before running the command and then verifying that the only Xcode project is for `App` or by manually modifying any of the projects and verifying they don't update)
* Add TuistConfig manifest model
* Add TuistConfig to the TuistGenerator
* Use the TuistConfig generationOptions to determine whether the manifest elements should be generated
* Generate a TuistConfig.swift when initialing a project using 'tuist init'
* Add documentation
* Add documentation
* Update CHANGELOG
* Fix tests
* Add a new case to Info.plist, dictionary
* Add .dictionary to the model in TuistGenerator
* Add DerivedFile model
* Add documentation
* Create a custom type for the InfoPlist dictionary
* Fix tests
* Update CHANGELOG
* Add logic to write Info.plist content
* Test DerivedFileGenerator
* Generate the file elements and the right configuration path
* Add tests
* Include Minitest::Assertions namespace
* Fix acceptance tests
* Fix tests
* Add test that asserts that a codable & equatable object can be encoded and decoded, resulting in the same object
* Remove not used decoding logic from the InfoPlist.Value enum.
Moreover, update its tests to use the new XCTAssertCodable helper.
* Simplify the generation logic by setting the target.infoplist attribute pointing to the Info.plist generated in the Derived folder
- Updating lint rules to allow static products to depend on dynamic frameworks
- Updating fixture to include scenario where a static framework depends on a dynamic framework
Test Plan:
- Verify unit tests pass via `swift tests`
- Verify acceptance tests pass via `bundle exec rake tests`
Manually:
- Run `tuist generate` within `fixtures/ios_app_with_static_frameworks`
- Verify the generation is successful
- Open the generated workspace
- Verify D is embedded in App and CTests
- Verify the app compiles runs
Part of https://github.com/tuist/tuist/issues/425
- Renaming the generated manifest target to include an `_` separator instead `-` which produces an invalid product name.
- This was causing Xcode to automatically re-name it when opening the project
Test Plan:
- Generate `fixtures/ios_app_with_tests` via `tuist generate`
- Run `git add . -f` to stage the generated project
- Open the project in Xcode
- Verify the manifest target `App_manifest` doesn't get renamed by Xcode within the Scheme and project
- Verify the manifest target can still build successfully
* Setup webpacker for typescript
* Typescript is working
* Add documentation to set up the Galaxy project and start contributing to it
* Add Storybook
* Add Jest
* Remove tuistenv from the .gitignore
* Run rubocop
* Implement class to generate the dotgraph as a string
* Add GraphCommand
* Register command
* Add command to export the graph
* Fix graph syntax error
* Don't generate manifest targets when printing the graph
* Add tests
* Update CHANGELOG
* Add documentation
* Add the graph.dot file to the gitignore
* Address comments
* Don't lint when generating the graph
* Add command to output the graph to the standard output
* Make Graph and nodes conform Encodable
* Print the graph as a json
* Some fixes after rebasing
* Pass file and line arguments
* Keep models and attributes as internal
* Extract the node classes into their own files
* Add DotGraph* elements
* Extract FrameworkNode from GraphNode
* Add tests
* Address comments
Resolves https://github.com/tuist/tuist/issues/417
- Updating SDK dependency paths to be based on the developer directory and the platform SDK root path
Test Plan:
- generate the fixture `fixtures/ios_app_with_sdk` via `tuist generate`
- Verify the linked system frameworks and libraries have the correct path set based on the platform
Resolves https://github.com/tuist/tuist/issues/174
Continuation of https://github.com/tuist/tuist/pull/272 by @steprescott
### Short description
In some cases specifying the status of the frameworks or libraries to link against is needed (e.g. weakly linking frameworks).
### Solution
- A new `.sdk` dependency type is being introduced
usage:
```swift
Target(name: "App",
platform: .iOS,
product: .app,
bundleId: "io.tuist.App",
infoPlist: "Info.plist",
sources: "Sources/**",
dependencies: [
.sdk(name: "CloudKit.framework", status: .required),
.sdk(name: "StoreKit.framework", status: .optional),
.sdk(name: "libc++.tbd"),
])
```
### Test Plan
- Verify unit tests pass via `swift test`
- Verify acceptance tests pass via `bundle rake exec features`
- Manually generate `fixtures/ios_app_with_sdk` via `tuist generate`
- Verify the appropriate libraries are included in the generated project
### Notes
Credit goes to @steprescott and [`XcodeGen`](https://github.com/yonaskolb/XcodeGen) - this PR is based on their work!
Resolves https://github.com/tuist/tuist/issues/414
`BuildPhaseGenerator` will not generate empty `settings` attribute for source `PBXBuildFile` elements when compiler flags are not specified.
Test Plan:
- Close Xcode
- Generate `fixtures/ios_app_with_frameworks` fixture
- Open generated .xcodeproj in a non-Xcode editor (i.e vim), ensure empty `settings ={}` attributes have not been generated
- Adding Xcode10 constants to maintain backwards compatibiltiy (Xcode 11 is still in beta!)
Test Plan:
- Verify unit tests pass via `swift test`
- Verify acceptance tests pass via `bundle exec rake features`
Resolves https://github.com/tuist/tuist/issues/409
### Short description
Calling `tuist generate` on the same project multiple times can yield a different `.xcodeproj` file each time.
### Solution
Sort elements ahead of adding them to their corresponding xcodeproj container.
### Implementation
- Update generator integration tests to shuffle sources / headers
- Sort files added within `BuildPhaseGenerator`
- Update generator integration tests to shuffle additional files
- Update `ProjectFilesSortener` to be stable
- Update `LinkGenerator` to sort dependencies
### Test Plan
- Ensure unit tests pass via `swift test`
- Ensure acceptance tests pass via `bundle exec rake features`
Generate the fixture `fixtures/ios_app_with_tests/` and verify the generated project is identical each time
```
$ cd fixtures/ios_app_with_tests/
$ touch Sources/Source{A..Z}.swift
$ for i in {1..5}; do tuist generate > /dev/null && md5 App.xcodeproj/project.pbxproj; done
```
# Short description
The `FileManager` `url(for:in:appropriateFor:create:)` method, when configured to create a temporary directory, fails after 1000 calls with: Error Domain=NSCocoaErrorDomain Code=512 "The file couldn’t be saved."
http://openradar.appspot.com/50553219
# Solution
We need to ensure the temporary directory is removed after `FileHandler.replace` method finished.
- Removing empty test file (seems to upset SwiftFormat)
- Doing a sweep of swiftformat fixes
- Bumping circleci image to Xcode 10.2.1
Test Plan:
- Verify tuist builds via `swift build`
- Verify tests pass via `swift tests`
- Verify swiftformat runs without issues
- Verify swiftformat runs on CI
Resolves https://github.com/tuist/tuist/issues/387
- We now pass the `-q` (quiet) option to `unzip` to suppress the verbose output
Test Plan:
- build this version locally
- run `swift run tuistenv update`
- Verify the logs don't display the unzipped files
Kas