Rename features to guides
This commit is contained in:
Pedro Piñera
parent
8398c4a110
commit
6284c066f5
|
|
@ -3,7 +3,7 @@ import ProjectDescription
|
|||
/// Project helpers are functions that simplify the way you define your project.
|
||||
/// Share code to create targets, settings, dependencies,
|
||||
/// Create your own conventions, e.g: a func that makes sure all shared targets are "static frameworks"
|
||||
/// See https://docs.tuist.io/features/helpers/
|
||||
/// See https://docs.tuist.io/guides/helpers/
|
||||
|
||||
extension Project {
|
||||
/// Helper function to create the Project for this ExampleApp
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ This document contains a list of recommendations for conventions that we'd follo
|
|||
|
||||
### Dependencies
|
||||
|
||||
- **Explicit definition:** Dependencies can be defined implicitly through build settings. Xcode is smart enough to detect them and determine the order in which targets should be built. Although implicitness might work fine in small projects, as they get larger, it might turn into a source of issues and slowness. Default to explicit definition of dependencies using the [dependencies API](/features/dependencies/) that Tuist provides. Tuist has handy built-in features such as [tuist graph](/commands/graph/) or detection of circular dependencies that rely on dependencies being explicitly defined.
|
||||
- **Explicit definition:** Dependencies can be defined implicitly through build settings. Xcode is smart enough to detect them and determine the order in which targets should be built. Although implicitness might work fine in small projects, as they get larger, it might turn into a source of issues and slowness. Default to explicit definition of dependencies using the [dependencies API](/guides/dependencies/) that Tuist provides. Tuist has handy built-in features such as [tuist graph](/commands/graph/) or detection of circular dependencies that rely on dependencies being explicitly defined.
|
||||
- **XCTest dependency:** If a target that is not a test target depends on `XCTest`, declare the dependency explicitly with `.xctest`.
|
||||
- **Avoid re-exported modules:** If a target A, re-exports a dependency B using the syntax `@_exported`, to a target C, B should be a dependency of C. Dependencies defined through [re-exports](https://github.com/apple/swift/blob/main/docs/Modules.rst#modules-can-re-export-other-modules) create implicit dependencies that complicate [caching](/building-at-scale/caching/). If that setup is not possible becase it leads to duplicated symbols, you might consider wrapping the transitive static dependency into a dynamic target.
|
||||
|
||||
|
|
|
|||
|
|
@ -247,7 +247,7 @@ the decision process has been notably simplified.
|
|||
Since Tuist supports defining resources in libraries,
|
||||
we recommend sticking to **static libraries**,
|
||||
unless you come across scenarios where a dynamic framework is more suitable.
|
||||
Bear in mind that Tuist makes changing the product a seamless process as long as you use the [standard interface](/features/resources/) for accessing resources.
|
||||
Bear in mind that Tuist makes changing the product a seamless process as long as you use the [standard interface](/guides/resources/) for accessing resources.
|
||||
|
||||
### Frequently asked questions
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ description: 'Learn how to edit your manifest files using Xcode and get document
|
|||
### Context
|
||||
|
||||
One of the advantages of defining your projects in [Swift](https://swift.org/) is that we can leverage Xcode and the Swift compiler to safely edit the projects with syntax auto-completion and documentation.
|
||||
Tuist provides a command, `tuist edit`, which generates and opens a temporary Xcode project that includes all the manifest files in the current directory, and the files the manifests depend on _(e.g. [project description helpers](/features/helpers/))_.
|
||||
Tuist provides a command, `tuist edit`, which generates and opens a temporary Xcode project that includes all the manifest files in the current directory, and the files the manifests depend on _(e.g. [project description helpers](/guides/helpers/))_.
|
||||
|
||||
### Command
|
||||
|
||||
|
|
|
|||
|
|
@ -54,4 +54,4 @@ Since platform is an optional argument, we can also call the command without the
|
|||
|
||||
If `.string` and `.files` don't provide enough flexibility, you can leverage the [Stencil](https://github.com/stencilproject/Stencil) templating language via the `.file` case. Besides that, you can also use additional filters defined [here](https://github.com/SwiftGen/StencilSwiftKit#filters)
|
||||
|
||||
Templates can import [project description helpers](/features/helpers/). Just add `import ProjectDescriptionHelpers` at the top, and extract reusable logic into the helpers.
|
||||
Templates can import [project description helpers](/guides/helpers/). Just add `import ProjectDescriptionHelpers` at the top, and extract reusable logic into the helpers.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Dependencies
|
||||
slug: '/features/dependencies'
|
||||
title: Defining dependencies
|
||||
slug: '/guides/dependencies'
|
||||
description: Defining dependencies between modules is a straightforward task in Tuist. This document describes how to use this feature, and all types of dependencies that targets can define.
|
||||
---
|
||||
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Environment
|
||||
slug: '/features/environment'
|
||||
title: Generation-time configuration
|
||||
slug: '/guides/environment'
|
||||
description: Learn how to leverage environment variables that can be read from the manifest files.
|
||||
---
|
||||
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Manifest code-sharing
|
||||
migrated_path: '/features/helpers'
|
||||
title: Sharing code across manifests
|
||||
migrated_path: '/guides/helpers'
|
||||
description: Project description helpers are a group of Swift files that can be accessed from any project manifest. They are useful to extract common patterns, define project conventions, or simplify the definition of projects.
|
||||
---
|
||||
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Accessing resources
|
||||
slug: '/features/resources'
|
||||
slug: '/guides/resources'
|
||||
description: 'In this page documents how Tuist synthesizes accessors for resources to provide an interface that is consistent across all target products (e.g. framework. library).'
|
||||
---
|
||||
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Shell autocompletion
|
||||
slug: '/features/shell-autocompletion'
|
||||
title: Setting up your shell
|
||||
slug: '/guides/shell-autocompletion'
|
||||
description: 'To ease usage of tuist, learn how you can generate autocompletions for your shell'
|
||||
---
|
||||
|
||||
|
|
@ -1,9 +1,11 @@
|
|||
---
|
||||
title: Statistics
|
||||
slug: '/features/stats'
|
||||
title: Helping Tuist
|
||||
slug: '/guides/stats'
|
||||
description: Learn about Tuist Stats
|
||||
---
|
||||
|
||||
### Sending usage statistics
|
||||
|
||||
Tuist sends some **anonymous** analytics events to track the usage of the tool.
|
||||
Having statistics about Tuist's usage helps contributors to make informed decision and better prioritize future work.
|
||||
For example, if a command is only used by 1% of the users, it might not get prioritized for enhancements in the future.
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Version management
|
||||
slug: '/features/version-management'
|
||||
title: Managing Tuist versions
|
||||
slug: '/guides/version-management'
|
||||
description: Tuist comes with its own version management that is deterministic and ensures that everyone in the team uses the same version of Tuist. This document explains how to use it, and what are the commands available to pin projects or the environment to specific versions of Tuist.
|
||||
---
|
||||
|
||||
|
|
@ -97,7 +97,7 @@ For local:
|
|||
.package(path: "MyLibrary")
|
||||
```
|
||||
|
||||
Targets can then depend on products from these Swift Packages. See [Dependencies](/features/dependencies)
|
||||
Targets can then depend on products from these Swift Packages. See [Dependencies](/guides/dependencies)
|
||||
|
||||
:::note Package.resolved
|
||||
Tuist creates a `.package.resolved` file, so your team can share the same versions of dependencies without committing your workspace.
|
||||
|
|
@ -121,7 +121,7 @@ Each target in the list of project targets can be initialized with the following
|
|||
| `headers` | The target headers. | [`Headers`](#headers) | No | |
|
||||
| `entitlements` | Path to the entitlement file. | [`Path`](#path) | No | |
|
||||
| `actions` | Target actions allow defining extra script build phases. | [`[TargetAction]`](#target-action) | No | `[]` |
|
||||
| `dependencies` | List of target dependencies. | [`[TargetDependency]` ](/features/dependencies) | No | `[]` |
|
||||
| `dependencies` | List of target dependencies. | [`[TargetDependency]` ](/guides/dependencies) | No | `[]` |
|
||||
| `sources` | Source files that are compiled by the target. Any playgrounds matched by the globs used in this property will be automatically added. | [`SourceFilesList`](#source-file-list) | Yes | |
|
||||
| `settings` | Target build settings and configuration files. | [`Settings`](#settings) | No | |
|
||||
| `coreDataModels` | Core Data models. | [`[CoreDataModel]`](#core-data-model) | No | |
|
||||
|
|
|
|||
|
|
@ -84,7 +84,7 @@ and lets developers know that they should change the manifest files instead.
|
|||
|
||||
You can use a tool like [xcdiff](https://github.com/bloomberg/xcdiff) for that.
|
||||
|
||||
#### Use [project description helpers](/features/helpers/)
|
||||
#### Use [project description helpers](/guides/helpers/)
|
||||
|
||||
They allow defining your own abstractions for defining your projects,
|
||||
and most importantly,
|
||||
|
|
|
|||
|
|
@ -11,15 +11,36 @@ module.exports = {
|
|||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Features',
|
||||
label: 'Guides',
|
||||
items: [
|
||||
'features/dependencies',
|
||||
'features/helpers',
|
||||
'features/resources',
|
||||
'features/environment',
|
||||
'features/version-management',
|
||||
'features/shell-autocompletion',
|
||||
'features/stats',
|
||||
'guides/dependencies',
|
||||
'guides/helpers',
|
||||
'guides/resources',
|
||||
'guides/environment',
|
||||
'guides/version-management',
|
||||
'guides/shell-autocompletion',
|
||||
'guides/stats',
|
||||
],
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Commands',
|
||||
items: [
|
||||
'commands/edit',
|
||||
'commands/generate',
|
||||
'commands/focus',
|
||||
'commands/signing',
|
||||
'commands/build',
|
||||
'commands/test',
|
||||
'commands/scaffold',
|
||||
'commands/linting',
|
||||
'commands/graph',
|
||||
'commands/up',
|
||||
'commands/migration',
|
||||
'commands/documentation',
|
||||
'commands/secrets',
|
||||
'commands/clean',
|
||||
'commands/dependencies',
|
||||
],
|
||||
},
|
||||
{
|
||||
|
|
@ -50,27 +71,6 @@ module.exports = {
|
|||
'building-at-scale/best-practices',
|
||||
],
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Commands',
|
||||
items: [
|
||||
'commands/edit',
|
||||
'commands/generate',
|
||||
'commands/focus',
|
||||
'commands/signing',
|
||||
'commands/build',
|
||||
'commands/test',
|
||||
'commands/scaffold',
|
||||
'commands/linting',
|
||||
'commands/graph',
|
||||
'commands/up',
|
||||
'commands/migration',
|
||||
'commands/documentation',
|
||||
'commands/secrets',
|
||||
'commands/clean',
|
||||
'commands/dependencies',
|
||||
],
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Contributors',
|
||||
|
|
|
|||
|
|
@ -93,7 +93,7 @@ Apart from the setup of new apps it also turned out to be a big pain to maintain
|
|||
|
||||
### What’s the feature that you like the most from Tuist and why?
|
||||
|
||||
There are so many nice features in Tuist already but I think the [project description helpers](https://docs.tuist.io/features/helpers/) are my favorite. It allows us to generalize and reuse the way an app or framework is configured.
|
||||
There are so many nice features in Tuist already but I think the [project description helpers](https://docs.tuist.io/guides/helpers/) are my favorite. It allows us to generalize and reuse the way an app or framework is configured.
|
||||
|
||||
### Do you use project description helpers? If so, how? Would you mind adding a code snippet that illustrates your usage.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
name: Autocompletions
|
||||
migrated_path: '/features/shell-autocompletion'
|
||||
migrated_path: '/guides/shell-autocompletion'
|
||||
excerpt: ''
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
name: Local dependencies
|
||||
migrated_path: '/features/dependencies'
|
||||
migrated_path: '/guides/dependencies'
|
||||
exceprt: ''
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
name: Dynamic configuration
|
||||
migrated_path: '/features/environment'
|
||||
migrated_path: '/guides/environment'
|
||||
excerpt: ''
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
name: Project description helpers
|
||||
migrated_path: '/features/helpers'
|
||||
migrated_path: '/guides/helpers'
|
||||
excerpt: ''
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
name: Managing versions
|
||||
migrated_path: '/features/version-management'
|
||||
migrated_path: '/guides/version-management'
|
||||
excerpt: ''
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
name: Accessing resources
|
||||
migrated_path: '/features/resources'
|
||||
migrated_path: '/guides/resources'
|
||||
excerpt: ''
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
name: Stats
|
||||
migrated_path: '/features/stats'
|
||||
migrated_path: '/guides/stats'
|
||||
exceprt: Learn about Tuist Stats
|
||||
---
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ author: pepibumur
|
|||
Tuist 1.1.0 has been released and is shorter than usual because we have committed to a fixed biweekly.
|
||||
In the past,
|
||||
users were in situations where their projects were pointing to commits in main.
|
||||
Although that's possible thanks to [Tuist's version management](https://docs.tuist.io/features/version-management/), that's an undesirable state to be in.
|
||||
Although that's possible thanks to [Tuist's version management](https://docs.tuist.io/guides/version-management/), that's an undesirable state to be in.
|
||||
We chose two weeks as the cadence because a week is to short as to be able to ship noticeable changes,
|
||||
and more than two weeks likely leaves users waiting for improvements and bug fixes coming along with new versions.
|
||||
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ let baseSettings: [String: SettingValue] = [
|
|||
|
||||
This is not ideal. Having to repeat the strings manually and finding the possible values is not only tedious, but also
|
||||
might lead to errors, since typos in strings are a common problem. Initially, I found myself using a few functions in
|
||||
my [project description helpers](https://docs.tuist.io/features/helpers/) to make the settings both type safety and to reduce duplication
|
||||
my [project description helpers](https://docs.tuist.io/guides/helpers/) to make the settings both type safety and to reduce duplication
|
||||
of the strings. I raised the topic in the Tuist Slack group and adding these functions to `ProjectDescription` was a
|
||||
welcome idea. This is exactly within the goals of Tuist: to make developers' life easier and the task of generating
|
||||
projects less error prone. From now on, the code above can be written like this:
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ There are also build phases, targets, or schemes, for which Xcode doesn't provid
|
|||
Other teams resort to scripts that run some checks on the projects,
|
||||
but that results in a poor experience for developers because those checks are not built into their workflows.
|
||||
|
||||
Tuist solves this by providing [project description helpers](https://docs.tuist.io/features/helpers/).
|
||||
Tuist solves this by providing [project description helpers](https://docs.tuist.io/guides/helpers/).
|
||||
All you need to do is to define what types of projects are supported,
|
||||
and codify them into functions that return templated projects:
|
||||
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ At this point, you may wonder how Tuist relates to this dynamism I'm talking abo
|
|||
|
||||
Here are some examples of things that we were able to provide by leveraging the dynamism of project generation:
|
||||
|
||||
- Having consistency across projects and targets by leveraging [project description helpers](https://docs.tuist.io/features/helpers/).
|
||||
- Having consistency across projects and targets by leveraging [project description helpers](https://docs.tuist.io/guides/helpers/).
|
||||
- [Defining dependencies](/docs/dependencies/local/) explicitly with a simple and unified DSL.
|
||||
- [Setting up](/docs/commands/up/) the environment deterministically to ensure Xcode behaviors and builds are reproducible.
|
||||
- Throw errors early when projects have invalid configurations.
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ It's Friday, and that means time for a new Tuist release. With the aim of releas
|
|||
|
||||
### Disable SwiftLint in the generated source files
|
||||
|
||||
With the introduction of [synthesized accessors for resources](https://docs.tuist.io/features/resources/) some users reported that SwiftLint failed because it linted the generated files. We [fixed](https://github.com/tuist/tuist/pull/1574) it by adding annotations in the generated files to disable [SwiftLint](https://github.com/realm/SwiftLint) in them.
|
||||
With the introduction of [synthesized accessors for resources](https://docs.tuist.io/guides/resources/) some users reported that SwiftLint failed because it linted the generated files. We [fixed](https://github.com/tuist/tuist/pull/1574) it by adding annotations in the generated files to disable [SwiftLint](https://github.com/realm/SwiftLint) in them.
|
||||
|
||||
### Fix the path resolution for synthesized resource accessors
|
||||
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ One of the downsides of accessing resources using strings is that nothing preven
|
|||
|
||||
We think it's a brilliant idea worth incorporating into Tuist, and that's what we did in this release. Tuist automatically generates a Swift interface for accessing the resources and adds it to the target automatically. Users don't have to install SwiftGen, ensure that their targets are well-configured, or add extra lanes into their `Fastfiles`. The generation of those interfaces happens seamlessly at project generation time.
|
||||
|
||||
You can check out [this documentation page](https://docs.tuist.io/features/resources/) to learn more about the feature.
|
||||
You can check out [this documentation page](https://docs.tuist.io/guides/resources/) to learn more about the feature.
|
||||
|
||||
## Lint your Swift code
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ In this blog post, I'll unfold the areas we’ll focus on in 2021.
|
|||
|
||||
With project generation, we gave teams a simple interface to describe their modular projects.
|
||||
By design, we chose [Swift](https://developer.apple.com/swift/) as the language for describing them.
|
||||
It was a great idea because it allowed us to provide a great developer experience and features like [project description helpers](https://docs.tuist.io/features/helpers/).
|
||||
It was a great idea because it allowed us to provide a great developer experience and features like [project description helpers](https://docs.tuist.io/guides/helpers/).
|
||||
|
||||
As more projects adopted Tuist,
|
||||
we realized it’d also be useful for teams to extract Tuist-related files into a different repository to make them organization-wide resources.
|
||||
|
|
|
|||
Loading…
Reference in New Issue