Add a note to the scratch document

This commit is contained in:
Pedro Piñera 2020-03-31 16:38:52 +02:00
parent d83d73ffcb
commit d671f40063
14 changed files with 31 additions and 43 deletions

View File

@ -1,6 +1,5 @@
---
name: Architecture
order: 4
excerpt: 'This document describes how the project is architected and what are different areas of responsibilities.'
---

View File

@ -1,6 +1,5 @@
---
name: Changelog guidelines
order: 7
excerpt: Read about the guidelines that the project embrace for the style of the CHANGELOG file. Every user-facing change added to the project requires changes in this file that is useful for users to know what's coming with every new version of Tuist.
---

View File

@ -1,6 +1,5 @@
---
name: Code of conduct
order: 8
excerpt: This document contains rules of behaviour and good conduct to have a healthy community of users, contributors, and maintainers. In a nutshell, every person involved in this project should be nice with everyone around them.
---

View File

@ -1,6 +1,5 @@
---
name: Code reviews
order: 2
excerpt: For contributors and maintainers that help review pull requests on GitHub, this page includes a checklist with some important aspects that they should look at. It's not meant to be an exhaustive checklist but rather a reference.
---

View File

@ -1,6 +1,5 @@
---
name: Core team
order: 9
excerpt: The core team is a group of contributors that demonstrated a lasting enthusiasm for the project and the community. This document contains who they are, what are their responsibilities, and what's the process for adding new members.
---

View File

@ -1,6 +1,5 @@
---
name: Getting started
order: 1
excerpt: This is page contains a handful of resources and tips for users that are interested in contributing to the project. From how the project is structured to what utilities are available, including bits about the testing strategies that we follow.
---

View File

@ -1,6 +1,5 @@
---
name: Manifesto
order: 10
excerpt: This page describes principles that are pillars to the design and development of Tuist. They evolve with the project and are meant to ensure a sustainable growth that is well-aligned with the project foundation.
---
@ -90,10 +89,10 @@ but prevent future developers from breaking that logic.
<!-- ## 7. Write code for humans
The code that we write can make a huge difference between a buggy and unmaintainable code base,
The code that we write can make a huge difference between a buggy and unmaintainable code base,
and a stable and maintainable one.
Write beautiful and concise code that is **easy to read and understand**.
Leverage the abstractions and primitives provided by the programming language,
Leverage the abstractions and primitives provided by the programming language,
Swift,
to create a solid structure made of simple pieces with scoped responsibilities.
Don't add code to Tuist that reads like a long and mysterious bash script.
@ -101,5 +100,5 @@ The programming patterns and paradigms that you might apply when building apps m
In fact, a pattern like MVP, is also valid in the context of CLIs with the difference that the view is the CLI output *(chunks of data sent through the standard output and error)*.
Code that reads like a book encourages contributions,
Code that reads like a book encourages contributions,
and contributions bring new ideas to the table that -->

View File

@ -1,6 +1,5 @@
---
name: Performance
order: 12
excerpt: This page describes the project's performance testing strategy.
---
@ -11,7 +10,7 @@ To test out generation speeds and to provide some utilities to aid profiling Tui
- `fixturegen`: A tool to generate large fixtures
- `tuistbench`: A tool to benchmark Tuist
Those tools are located within the [`tools/`](https://github.com/tuist/tuist/blob/master/tools) directory.
Those tools are located within the [`tools/`](https://github.com/tuist/tuist/blob/master/tools) directory.
## Fixture Generator (`fixturegen`)
@ -55,7 +54,7 @@ Runs : 5
Result
- cold : 0.72s
- warm : 0.74s
```
Markdown format:
@ -68,11 +67,9 @@ swift run tuistbench \
```
| Fixture | Cold | Warm |
| ------------------ | ------| ----- |
| ------------------ | ----- | ----- |
| ios_app_with_tests | 0.72s | 0.72s |
**Benchmark (single fixture):**
Console format:
@ -90,7 +87,6 @@ Result
- warm : 0.75s vs 0.79s (⬇︎ 0.04s 5.63%)
```
Markdown format:
```sh
@ -101,11 +97,10 @@ swift run tuistbench \
--format markdown
```
| Fixture | New | Old | Delta |
| --------------- | ------ | ---- | -------- |
| ios_app_with_tests _(cold)_ | 0.73s | 0.79s | ⬇︎ 7.92% |
| ios_app_with_tests _(warm)_ | 0.79s | 0.79s | ≈ |
| Fixture | New | Old | Delta |
| ---------------------------- | ----- | ----- | -------- |
| ios*app_with_tests *(cold)\_ | 0.73s | 0.79s | ⬇︎ 7.92% |
| ios*app_with_tests *(warm)\_ | 0.79s | 0.79s | ≈ |
**Benchmark (multiple fixtures):**
@ -113,11 +108,11 @@ A fixture list `json` file is needed to specify multiple fixtures, here's an exa
```json
{
"paths": [
"/path/to/fixtures/ios_app_with_tests",
"/path/to/fixtures/ios_app_with_carthage_frameworks",
"/path/to/fixtures/ios_app_with_helpers"
]
"paths": [
"/path/to/fixtures/ios_app_with_tests",
"/path/to/fixtures/ios_app_with_carthage_frameworks",
"/path/to/fixtures/ios_app_with_helpers"
]
}
```
@ -161,12 +156,11 @@ swift run tuistbench \
--format markdown
```
| Fixture | New | Old | Delta |
| --------------- | ------ | ---- | -------- |
| ios_app_with_tests _(cold)_ | 0.73s | 0.79s | ⬇︎ 7.92% |
| ios_app_with_tests _(warm)_ | 0.79s | 0.79s | ≈ |
| ios_app_with_carthage_frameworks _(cold)_ | 0.79s | 0.85s | ⬇︎ 7.36% |
| ios_app_with_carthage_frameworks _(warm)_ | 0.77s | 0.81s | ⬇︎ 5.26% |
| ios_app_with_helpers _(cold)_ | 2.29s | 2.43s | ⬇︎ 5.80% |
| ios_app_with_helpers _(warm)_ | 1.97s | 2.15s | ⬇︎ 8.05% |
| Fixture | New | Old | Delta |
| ------------------------------------------ | ----- | ----- | -------- |
| ios*app_with_tests *(cold)\_ | 0.73s | 0.79s | ⬇︎ 7.92% |
| ios*app_with_tests *(warm)\_ | 0.79s | 0.79s | ≈ |
| ios*app_with_carthage_frameworks *(cold)\_ | 0.79s | 0.85s | ⬇︎ 7.36% |
| ios*app_with_carthage_frameworks *(warm)\_ | 0.77s | 0.81s | ⬇︎ 5.26% |
| ios*app_with_helpers *(cold)\_ | 2.29s | 2.43s | ⬇︎ 5.80% |
| ios*app_with_helpers *(warm)\_ | 1.97s | 2.15s | ⬇︎ 8.05% |

View File

@ -1,6 +1,5 @@
---
name: Release
order: 6
excerpt: Know more about the release process and cadence of Tuist.
---

View File

@ -1,6 +1,5 @@
---
name: Reporting bugs
order: 3
excerpt: This documentation page contains guidelines for reporting bugs that are found while using Tuist.
---

View File

@ -1,13 +1,16 @@
---
name: Scratch
order: 11
excerpt: Random ideas and notes for Tuist. Pseudocode and braindumps.
---
# Scratch
## March 31th 2020 - Compiling ProjectDescription with the Swift version of the minimum supported version of Xcode
A recent release of Tuist, 1.5.3 caused Tuist to stop working with versions of Xcode older than 11.4. After some debugging, we found out that it was the result of building the `ProjectDescription` framework with the version of Swift that is bundled with Xcode 11.4, 5.2. We should compile the framework with the Swift version of the minium supported Xcode version. We added a note to the `RELEASE.md` document for now, but we should consider automating this process on CI so that we don't make the same mistake again.
## March 26th 2020 - Acceptance tests and multiple versions of Xcode
I attempted to add set up GitHub actions to run the tests on multiple versions of Xcode and I realized that the acceptance tests that depend on precompiled frameworks an libraries can only run with a version of Xcode.
I attempted to add set up GitHub actions to run the tests on multiple versions of Xcode and I realized that the acceptance tests that depend on precompiled frameworks an libraries can only run with a version of Xcode.
I made the tradeoff of **always running the acceptance tests with the latest version of Xcode** to avoid increasing the cost of maintaining those tests.
This is a decision that we should revisit if we notice that we ship changes that break the backwards compatibility without us realizing it.
This is a decision that we should revisit if we notice that we ship changes that break the backwards compatibility without us realizing it.

View File

@ -1,6 +1,5 @@
---
name: Testing strategy
order: 5
excerpt: This page describes the project's testing strategy and what's the most suitable case for each of them.
---

View File

@ -42,4 +42,5 @@ import { Cloud, Users, Contributors, Architectures } from "./components/icons"
- [Code of conduct](/docs/contribution/code-of-conduct/)
- [Core team](/docs/contribution/changelog-guidelines/)
- [Manifesto](/docs/contribution/manifesto/)
- [Scratch](/docs/contribution/scratch/)
- [Performance](/docs/contribution/performance/)

View File

@ -107,7 +107,7 @@ Tuist looks up CocoaPods using Bundler. If it's not defined, it falls back to th
<Message
info
title="Repository update"
description="The underlying 'pod install' is executed with the '--update-repo' argument to ensure the local repository of pod specs is up to date."
description="The underlying 'pod install' is executed with the `--update-repo` argument to ensure the local repository of pod specs is up to date."
/>
<Message
warning