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
Kas