Reorganize the sidebar content
This commit is contained in:
Pedro Piñera
parent
1dd3be22d5
commit
e23164569d
|
|
@ -50,7 +50,7 @@ The repository is a monorepo with multiple projects:
|
|||
|
||||
## Documentation 📝
|
||||
|
||||
Do you want to know more about what Tuist can offer you? Or perhaps want to contribute to the project and you need a starting point? You can check out the [project documentation](https://tuist.io/docs/usage/get-started/).
|
||||
Do you want to know more about what Tuist can offer you? Or perhaps want to contribute to the project and you need a starting point? You can check out the [project documentation](https://docs.tuist.io/tutorial/get-started/).
|
||||
|
||||
## Supported by great companies
|
||||
|
||||
|
|
|
|||
|
|
@ -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://tuist.io/docs/usage/helpers/
|
||||
/// See https://docs.tuist.io/features/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](/usage/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](/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.
|
||||
- **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](/usage/resources/) for accessing resources.
|
||||
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.
|
||||
|
||||
### 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](/usage/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](/features/helpers/))_.
|
||||
|
||||
### Command
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ slug: '/commands/migration'
|
|||
description: 'Learn how to use the migration commands to smooth the adoption of Tuist from your projects.'
|
||||
---
|
||||
|
||||
To help developers with the process of [adopting Tuist](/usage/adoption-guidelines/),
|
||||
To help developers with the process of [adopting Tuist](/tutorial/adoption-guidelines/),
|
||||
Tuist provides a set of commands under `tuist migration`.
|
||||
|
||||
### Extract build settings into xcode build configuration files
|
||||
|
|
|
|||
|
|
@ -50,4 +50,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](/usage/helpers/). Just add `import ProjectDescriptionHelpers` at the top, and extract reusable logic into the helpers.
|
||||
Templates can import [project description helpers](/features/helpers/). Just add `import ProjectDescriptionHelpers` at the top, and extract reusable logic into the helpers.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Dependencies
|
||||
slug: '/usage/dependencies'
|
||||
slug: '/features/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: '/usage/environment'
|
||||
slug: '/features/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: '/usage/helpers'
|
||||
migrated_path: '/features/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: '/usage/resources'
|
||||
slug: '/features/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: '/usage/shell-autocompletion'
|
||||
slug: '/features/shell-autocompletion'
|
||||
description: 'To ease usage of tuist, learn how you can generate autocompletions for your shell'
|
||||
---
|
||||
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Statistics
|
||||
slug: '/usage/stats'
|
||||
slug: '/features/stats'
|
||||
description: Learn about Tuist Stats
|
||||
---
|
||||
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Managing versions
|
||||
slug: '/usage/managing-versions'
|
||||
title: Version management
|
||||
slug: '/features/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.
|
||||
---
|
||||
|
||||
|
|
@ -10,7 +10,7 @@ If a tool is written in Ruby or Javascript, we can use dependency managers like
|
|||
|
||||
Although the [Swift Package Manager](https://swift.org/package-manager/) supports defining dependencies to be linked from your packages, it doesn’t support defining tools your project depends on. In other words, there isn’t a `swift exec tuist`. The closest option is [Mint](https://github.com/yonaskolb/mint), a non-official tool that aims to solve that problem. However, it means a dependency with another tool that should be installed in the environment, probably with [Homebrew](https://brew.sh), and whose versioning is out of our control. Besides introducing some inconvenience, it might result in a non-reproducible environment.
|
||||
|
||||
**Tuist opted for a simple, reproducible and transparent version management approach that is built into Tuist.** If you followed the [Get Started](/usage/get-started/) guide when you installed Tuist, you installed a tool called `tuistenv` that got renamed into `tuist`. Try executing the following command:
|
||||
**Tuist opted for a simple, reproducible and transparent version management approach that is built into Tuist.** If you followed the [Get Started](/tutorial/get-started/) guide when you installed Tuist, you installed a tool called `tuistenv` that got renamed into `tuist`. Try executing the following command:
|
||||
|
||||
```bash
|
||||
tuist --help-env
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Adoption guidelines
|
||||
slug: '/usage/adoption-guidelines'
|
||||
slug: '/tutorial/adoption-guidelines'
|
||||
description: This page contains guidelines for migrating existing Xcode projects to Tuist.
|
||||
---
|
||||
|
||||
|
|
@ -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](/usage/helpers/)
|
||||
#### Use [project description helpers](/features/helpers/)
|
||||
|
||||
They allow defining your own abstractions for defining your projects,
|
||||
and most importantly,
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Frequently asked questions
|
||||
slug: '/usage/faq'
|
||||
slug: '/tutorial/faq'
|
||||
description: Frequently Asked Questions
|
||||
---
|
||||
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Get started
|
||||
slug: '/usage/get-started'
|
||||
slug: '/tutorial/get-started'
|
||||
description: Learn how to install Tuist in your environment and generate your first project.
|
||||
---
|
||||
|
||||
|
|
@ -13,7 +13,7 @@ module.exports = {
|
|||
organizationName: 'tuist',
|
||||
projectName: 'tuist',
|
||||
customFields: {
|
||||
defaultDocsLandingPage: 'usage/get-started',
|
||||
defaultDocsLandingPage: 'tutorial/get-started',
|
||||
},
|
||||
themeConfig: {
|
||||
prism: {
|
||||
|
|
|
|||
|
|
@ -2,23 +2,29 @@ module.exports = {
|
|||
docs: [
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Usage',
|
||||
label: 'Tutorial',
|
||||
items: [
|
||||
'usage/get-started',
|
||||
'usage/helpers',
|
||||
'usage/dependencies',
|
||||
'usage/resources',
|
||||
'usage/environment',
|
||||
'usage/managing-versions',
|
||||
'usage/shell-autocompletion',
|
||||
'usage/adoption-guidelines',
|
||||
'usage/stats',
|
||||
'usage/faq',
|
||||
'tutorial/get-started',
|
||||
'tutorial/adoption-guidelines',
|
||||
'tutorial/faq',
|
||||
],
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Manifests',
|
||||
label: 'Features',
|
||||
items: [
|
||||
'features/dependencies',
|
||||
'features/helpers',
|
||||
'features/resources',
|
||||
'features/environment',
|
||||
'features/version-management',
|
||||
'features/shell-autocompletion',
|
||||
'features/stats',
|
||||
],
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Manifests reference',
|
||||
items: ['manifests/project', 'manifests/workspace', 'manifests/config'],
|
||||
},
|
||||
{
|
||||
|
|
|
|||
|
|
@ -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](/docs/usage/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/features/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: '/usage/shell-autocompletion'
|
||||
migrated_path: '/features/shell-autocompletion'
|
||||
excerpt: ''
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
name: Local dependencies
|
||||
migrated_path: '/usage/dependencies'
|
||||
migrated_path: '/features/dependencies'
|
||||
exceprt: ''
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
name: Dynamic configuration
|
||||
migrated_path: '/usage/environment'
|
||||
migrated_path: '/features/environment'
|
||||
excerpt: ''
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
name: Get started
|
||||
excerpt: ''
|
||||
migrated_path: '/usage/get-started'
|
||||
migrated_path: '/tutorials/get-started'
|
||||
redirect_from:
|
||||
- /docs/
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
name: Project description helpers
|
||||
migrated_path: '/usage/helpers'
|
||||
migrated_path: '/features/helpers'
|
||||
excerpt: ''
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
name: Managing versions
|
||||
migrated_path: '/usage/managing-versions'
|
||||
migrated_path: '/features/version-management'
|
||||
excerpt: ''
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
name: Accessing resources
|
||||
migrated_path: '/usage/resources'
|
||||
migrated_path: '/features/resources'
|
||||
excerpt: ''
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
name: Stats
|
||||
migrated_path: '/usage/stats'
|
||||
migrated_path: '/features/stats'
|
||||
exceprt: Learn about Tuist Stats
|
||||
---
|
||||
|
|
|
|||
|
|
@ -113,7 +113,7 @@ You can check out [the project issues](https://github.com/tuist/tuist/issues) th
|
|||
|
||||
## 📱 Start using it
|
||||
|
||||
Would you like to give Tuist a try? You can check out the [Get started](/docs/usage/get-started/) guide that explains how to install the tool and how to bootstrap your first project.
|
||||
Would you like to give Tuist a try? You can check out the [Get started](https://docs.tuist.io/tutorial/get-started/) guide that explains how to install the tool and how to bootstrap your first project.
|
||||
|
||||
## 📒 Resources
|
||||
|
||||
|
|
|
|||
|
|
@ -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://tuist.io/docs/usage/managing-versions/), that's an undesirable state to be in.
|
||||
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.
|
||||
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](/docs/usage/helpers/) to make the settings both type safety and to reduce duplication
|
||||
my [project description helpers](https://docs.tuist.io/features/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:
|
||||
|
|
@ -45,7 +45,7 @@ let baseSettings = SettingsDictionary()
|
|||
.swiftCompilationMode(.wholemodule)
|
||||
```
|
||||
|
||||
[Refer to the documentation](https://tuist.io/docs/usage/projectswift/#settingsdictionary) to see the list of built in
|
||||
[Refer to the documentation](/docs/usage/projectswift/#settingsdictionary) to see the list of built in
|
||||
functions, and also to learn how you can add your own to your project description helpers. If you find yourself using a
|
||||
function that others can leverage as well, don't hesitate to open a Pull Request adding them.
|
||||
|
||||
|
|
|
|||
|
|
@ -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](/docs/usage/helpers/).
|
||||
Tuist solves this by providing [project description helpers](https://docs.tuist.io/features/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](/docs/usage/helpers/).
|
||||
- Having consistency across projects and targets by leveraging [project description helpers](https://docs.tuist.io/features/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.
|
||||
|
|
@ -64,4 +64,4 @@ Still, it also leads them to waste time that they could otherwise spend building
|
|||
**Tuist takes care of those things, ensuring that we provide a consistent and easy experience that sparks joy.**
|
||||
|
||||
If you have been there and think it’s time to clean things up and make working with your project as enjoyable as it used to be when you first created the project with Xcode,
|
||||
you can check out our [Get Started](/docs/usage/get-started/) documentation.
|
||||
you can check out our [Get Started](https://docs.tuist.io/tutorial/get-started/) documentation.
|
||||
|
|
|
|||
|
|
@ -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](/docs/usage/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/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.
|
||||
|
||||
### 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](/docs/usage/resources/) to learn more about the feature.
|
||||
You can check out [this documentation page](https://docs.tuist.io/features/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](/docs/usage/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/features/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.
|
||||
|
|
|
|||
|
|
@ -1,10 +1,7 @@
|
|||
/** @jsx jsx */
|
||||
import { jsx, Styled, useThemeUI } from 'theme-ui'
|
||||
import { useStaticQuery, graphql, Link } from 'gatsby'
|
||||
import {
|
||||
faGithub,
|
||||
faTwitter,
|
||||
} from '@fortawesome/free-brands-svg-icons'
|
||||
import { faGithub, faTwitter } from '@fortawesome/free-brands-svg-icons'
|
||||
import { FontAwesomeIcon } from '@fortawesome/react-fontawesome'
|
||||
|
||||
export default () => {
|
||||
|
|
@ -12,12 +9,7 @@ export default () => {
|
|||
|
||||
const {
|
||||
site: {
|
||||
siteMetadata: {
|
||||
githubUrl,
|
||||
slackUrl,
|
||||
releasesUrl,
|
||||
twitterUrl,
|
||||
},
|
||||
siteMetadata: { githubUrl, slackUrl, releasesUrl, twitterUrl },
|
||||
},
|
||||
} = useStaticQuery(graphql`
|
||||
query {
|
||||
|
|
@ -48,7 +40,7 @@ export default () => {
|
|||
<div className="px-5 py-2">
|
||||
<Link
|
||||
alt="Opens the project documentation/"
|
||||
to="/docs/usage/get-started/"
|
||||
to="https://docs.tuist.io"
|
||||
className="text-base leading-6"
|
||||
sx={{ color: 'gray', ':hover': { color: 'primary' } }}
|
||||
>
|
||||
|
|
|
|||
|
|
@ -105,10 +105,7 @@ const Steroids = () => {
|
|||
Bootstrap, maintain, and interact with
|
||||
<br /> Xcode projects at any scale
|
||||
</div>
|
||||
<GradientButton
|
||||
title="GET STARTED"
|
||||
link="/docs/usage/get-started/"
|
||||
/>
|
||||
<GradientButton title="GET STARTED" link="https://docs.tuist.io/" />
|
||||
|
||||
<div
|
||||
sx={{ color: 'gray', mt: 5, textAlign: 'center' }}
|
||||
|
|
@ -569,7 +566,7 @@ const Contribute = () => {
|
|||
<div className="mt-8 flex justify-center">
|
||||
<div className="inline-flex rounded-md shadow">
|
||||
<Link
|
||||
to="/docs/usage/get-started/"
|
||||
to="https://docs.tuist.io"
|
||||
sx={{
|
||||
color: 'background',
|
||||
bg: 'primary',
|
||||
|
|
|
|||
Loading…
Reference in New Issue