* Add command for generating a secret
* Document secret command
* Update CHANGELOG
* Rename to edit your projects
* Some style fixes
Co-authored-by: Pedro Piñera <pedro@ppinera.es>
- The info plist generator is now a project mapper
- This helps keeps project modifications and side effects consistent to some of the others introduced
- Updated `Constants` to create a nested hierarchy for `DerivedDirectory` to allow grouping all related constants
- Updated side effect descriptions such that they are all `CustomStringContvertible` to allow using them in verbose logs
Test Plan:
- Run `tuist generate` within `fixtures/ios_app_with_watchapp2`
- Verify the Info.plist files continue to be generated to the `Derived/InfoPlists` directory
* Generate tuist generated file into workspace to solve ambiguity.
* Edit changelog.
* Move generating tuist-generated file to TuistKit.
* Fix BuildGraphInspector tests.
* Add test for no tuist workspace present.
* Add loadProjectWorkspace method to add tuist-generated to project workspace.
* Run swiftformat.
* Add support for specifying whether it should clean or not
* Update CHANGELOG
* Revert change to the Package.resolved
* Fix some issues
Co-authored-by: Pedro Piñera <pedro@ppinera.es>
* Add empty AutogeneratedSchemesGraphMapper
* Don't generate the schemes at generation time
* Implement AutogeneratedSchemesGraphMapper
* Update CHANGELOG
* Remove unnecessary method
* Turn the graph mapper into a project mapper
* Address some comments
Co-authored-by: Pedro Piñera <pedro@ppinera.es>
(Based on https://github.com/tuist/tuist/pull/1227)
### Short description
Applying modifications to the `Project` and `Target` models within `GraphMappers` may not always be possible due to the current `Graph` structure. To create a mapper that can generate info plists for example, the both the `Target` and the hosting `Project` needs to be modified.
e.g.
- #1357
- #1206
### Solution
Add "model mappers" that map `TuistCore` models ahead of converting them to a `Graph` representation.
### Implementation
- [x] Add model mappers
- [x] Add recursive manifest loader (loads all manifests without converting them)
- [x] Modify loading process to accommodate model mappers
- [x] Load all manifests upfront without conversion
- [x] Lint manifests
- [x] Convert manifests concurrently to models
- [x] Apply model mappers
### Test Plan
- Run `tuist generate` within any of the fixtures
- Verify projects can still be generated as before
- Verify acceptance tests pass
Part of: https://github.com/tuist/tuist/issues/1042
- Adding a new caching implementation of the manifest loader
- It works by wrapping the existing manifest loader and adds a caching layer ontop of it
- It attempts to first load a cached JSON representation of the manifest from `~/.tuist/Cache/Manifests` and then falls back to loading the manifest using the default implementation
- The hashes of the manifest content as well the helpers (`ProjectDescriptionHelpers`) are included with the cached manifest
- This allows comparing those hashes during the loading process and ensure the cache is updated from source when needed
- Overall this helps speed up the manifest loading process significantly as loading JSON from disk is much faster than compiling and running Swift manifest
- This approach ensures Swift manifests continue to be the source of truth while offering an optimization for the cases where the manifest doesn't change
- Caching can be enabled / disabled via `TUIST_CACHE_MANIFESTS=1` or `TUIST_CACHE_MANIFESTS=0`
- By default its enabled however this can be changed if we find any issues with this feature
Test Plan:
Modifying manifests:
- Run `tuist generate` on any of the fixtures
- Inspect the generation time
- Re-run `tuist generate`
- Inspect the generation time, which should be faster
- Note: most gains will be seen in larger projects with several manifests
- Modify any the project manifest (e.g. update the name)
- Re-run `tuist generate`
- Verify the updates are reflected in the generated project (i.e. the cache isn't incorrectly being used)
Modifying helpers:
- Repeat the test using a `fixture/ios_app_with_helpers`
- This time modify `Tuist/ProjectDescriptionHelpers`
- Re-run `tuist generate`
- Verify the updates are reflected in the generated project
Disabling caching:
- Remove the contents of `~/.tuist/Cache/Manifests`
- Run `TUIST_CACHE_MANIFESTS=0 tuist generate` on any of the fixtures
- Inspect the generation time
- Verify no cached manifests are added to `~/.tuist/Cache/Manifests`
* Update the models in ProjectDescription to add support for enabling the main thread checker
* Set disableMainThreadChecker depending on the given diagnostic options
* Fix tests
* Add unit tests
* Update documentation
* Update CHANGELOG
Co-authored-by: Pedro Piñera <pedro@ppinera.es>
* tuist eidt - added all manifest on tuist edit
* tuist edit - test project editor mapped with more than one Manifest
* tuist edit - updated project editor mapper, added ManifestFileLocatorTest
* tuist edit - updated aceptance test to check all schemes are building
* tuist edit - updated doc about now you can edit all the project manifests
* tuist edit - fix mock ManifestFileLocator.locateAll returning stubs
* fix - swift format
* changelog - updated with new tuist edit behaviour
* Update CHANGELOG.md
Co-Authored-By: Natan Rolnik <natanrolnik@gmail.com>
* tuist edit - fix unit tests
* swift format
* tuist edit - fix TuistKitTests
Co-authored-by: Natan Rolnik <natanrolnik@gmail.com>
* Add SettingsDictionary typealias for [String: SettingValue]
* Add SettingsDictionary functions to avoid using typed strings
* Add new SettingsDictionary functions to Changelog
* Improve changelog with links to PRs and usernames
(of contributors with 3+ PRs)
* Link also to PRs in Changelog
* Add documentation for SettingsDictionary
* Minor update to a SettingsDictionary transformer
* Update Changelog PR number
* Apply PR comments - part 1
* Apply more PR comments - part 2:
- Make SettingValue conform to ExpressibleByBooleanLiteral
- Add tests
- Change code signing methods
* Fix linting in SettingsTests
* Update Docs and Changelog
* Remove some of the SettingsDictionary functions
* Add SettingsDictionary functions table to website docs
* Add support for returning side effect descriptors from mappers
* Implement GraphMapperProvider to provide the mapper to be used depending on the config
* Add GraphMapperProviderTests
* Update CHANGELOG
* Test if the descriptors are concatenated in the right order
* Fix CHANGELOG. Some updates showed up in the wrong section
* Add GraphTargetNodeMapper
- Introduce a new component to allow mapping the graph without modifying the original (the graph and models are all reference types)
- The new component also ensures orphaned nodes are removed
Test Plan:
- Verify the tests pass
* Adopt `GraphMapping`
### Short description
When using `TuistGenerator` as a library, the generator component performs several actions:
- Loading of the graph
- Linting the graph
- XcodeProj generation
- Writing generation artifacts to disk
- Post generation actions
While convenient it doesn't offer flexibility to perform any custom linting or post processing on the generated XcodeProj representations or to selectively leverage some of those actions without the others.
### Solution
Based on a few early prototyping rounds on [tuist-labs](https://github.com/tuist/tuist-labs/tree/prototype/pipelines) and discussions on modularising Tuist even further, we can split the responsibilities of the generator to provide more flexibility and simplicity.
- Update the generator to return descriptors (it doesn't directly perform any operations - it's side effect free)
- Create a dedicated component to write those descriptions to disk as well as perform any required side effects
- Move some of the interactors that performed side effects out of the xcodeproj generation to help group them (e.g. CocoaPods / Swift PM)
- Create a new top level component to orchestrate all those steps to achieve the previous behaviour
_**Note:** These changes should have no impact on end users of Tuist_
### Implementation
- [x] Prototype `Descriptors` by having existing components return descriptors instead of performing actions (initially as duplicate methods for testing/prototyping)
- [x] Integrate a prototype of a high level `ProjectGenerator` that performs all the previous tasks with the `tuist generate` command
- [x] Verify acceptance tests don't flag any regressions
- [x] Delete duplicate methods (the non-descriptor) variants and update their corresponding unit tests
- [x] Integrate the updated generator with the other tuist commands
- [x] Come up with better component names to clarify their purpose _(current names were temporary to avoid name collisions however could be confusing)_
- [x] Update change log
### Test Plan
- Verify all acceptance tests pass
- Test out running `tuist generate` on any of the fixtures
* Pin XcodeProj to a branch until it's merged
* Add a way to specify PathRunnable in custom scheme
* Make scheme buildable when `tuist edit`-ing
* Added changelog entry
* Style correct
* Update Xcodeproj
* Using same path to tuist executable that was used to invoke the edit command
* Update documentation
* style update
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
Addresses https://github.com/tuist/tuist/issues/667
### Short description 📝
In order to support custom workspace schemes, we need to make the current scheme generation functions more generic and decouple it from the `Project` type. We now make graph look ups in the project scheme generation functions so that in a follow up pull request it will be easy to add custom workspace scheme support.
*Note that this pull request should make no user facing changes.*
I've pasted the steps listed in #667 below and marked the items completed by this pull request:
- [X] Changing the functions in the SchemeGenerator to use the graph for look ups by default (as this is the main difference between the project and workspace schemes)
- [X] Update the scheme model (in TuistGenerator) to start referencing targets using the .project(...)
- [ ] Expose workspace scheme type in the project manifest (ProjectDescription)
### Solution 📦
I've added a new `TargetReference` type in place of simple target names of type `String`. `TargetReference` has the name of a target and the relative path to its project. This `TargetReference` type works well for both project scheme generation and workspace scheme generation (in the follow up pull request). This new type enables functions in the scheme generator to do graph lookups to any target in the graph.
### Implementation 👩💻👨💻
- [X] Add `TargetReference` type to model
- [X] Change instances of simple target `String` types to `TargetReference` within the `Scheme` type in the model
- [X] Update `GeneratorModelLoader` to convert simple target name `String`s into `TargetReference` types by propagating the project path
- [X] Update instances where a simple target `String` type is expected to work with the name property in `TargetReference`
- [X] Update tests in `SchemesGeneratorTests`, `ProjectGeneratorTests`, `GeneratorModelLoaderTests`
* 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
* Support ability to locate multiple Tuist directories
- The logic has been modified to consult the file system and the cache when traversing the hierarchy
Test Plan:
- Verify unit tests continue to pass
* Update changelog
* Correct test to ensure multiple directories are supported
### 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
* Add Path struct
* Use Path for paths instead of String
* Add methods to get the current file directory and the manifest directory
* Fix the way we pass the SECRET_KEY
* Use the right syntax
* Simplify the paths implementation
* Update all path types to be Path
* Fix tests
* Update the fixture to use the new API
* Add documentation
* Don't pass the --tuist-manifest-dir argument
* Implement it as suggested on the PR
* 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
* Create `DeploymentTarget` descriptor
* Add `DeploymentTarget` to `Target` description
* Fix formatting issues
* Add `DeploymentTarget` to `TuistGenerator.Target`
* Update `TARGETED_DEVICE_FAMILY`
* Fix formatting
* Update `*_DEPLOYMENT_TARGET` in Build Settings
* Fix linter issue
* Make sure `platform` and `deploymentTarget` manifest parameters are compatible
* Move updating a deployment target to `updateTargetDervied` method
* Validate os version of deployment target
* Update Changelog
* Add tests to generator models
* Mark a breaking change in a changelog entry
* Move a regex utility function to `TuistCore`
* Make changes in public API of deployment target
* Fix unit tests of string regex
* Expose `version` property on deployment target
* Update Target documenatation
* Update acceptance tests
* Fix formatting
* Support mac device for iOS deployment target
* Fix lint formatting
* Enable catalyst support only if ipad is enabled for iOS deployment target
* Add deployment target tests to `ConfigGenerator`
Pedro Piñera Buendía