Merged
Conversation
Remove w-screen (100vw) from mobile nav, add overflow-x: hidden on html, constrain full-size images with max-w-full, and add overflow-x fallback on code blocks. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
📝 WalkthroughWalkthroughUpdates tutorial documentation with external links to Xcodegen and Tuist tools, restructures a section heading, bumps the xmlcoder Swift Package dependency from 0.18.0 to 0.18.1, and refines CSS overflow rules to prevent unwanted horizontal scrolling and constrain image widths. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related issues
Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Review rate limit: 0/1 reviews remaining, refill in 60 minutes.Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@Content/tutorials/tuist-xcode-project-setup.md`:
- Around line 15-19: Fix the three user-facing copy issues in the paragraph:
replace "eleviated" with "alleviated", change "There’s 2 leading tools" to
"There are two leading tools", and change "most any case" to "most cases" (or
"most other cases"); ensure the surrounding sentences read smoothly and keep
emphasis on not committing Xcode projects to the repo. Update the strings in the
Content/tutorials/tuist-xcode-project-setup.md block containing those phrases.
In `@Styling/styles/styles.css`:
- Around line 1319-1320: The stylelint failure is caused by missing empty line
before the declaration `overflow-x: auto;`; edit the CSS rule that contains the
`@apply whitespace-pre-wrap ...` declaration and insert a single blank line
immediately before the `overflow-x: auto;` line so there is an empty line
between the `@apply ...;` statement and the `overflow-x` declaration to satisfy
the `declaration-empty-line-before` rule.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 3171d718-dd0c-4cb0-a2ff-9f51a140d07b
📒 Files selected for processing (3)
Content/tutorials/tuist-xcode-project-setup.mdPackage.resolvedStyling/styles/styles.css
Comment on lines
+15
to
+19
| The Xcode project uses a _proprietary format_ that is notoriously difficult to work with, especially when dealing with merge conflicts in version control. In the ancient days, it was Storyboards and Xcode projects which were the biggest culprits of merge conflict hell. Coding your UI in UIKit and then SwiftUI eleviated the Storyboard issue but Xcode projects still remain. | ||
|
|
||
| This is where a tool which creates the Xcode project is most helpful. There’s 2 leading tools which I’d recommend: Xcodegen or Tuist. Xcodegen is great if you have a fairly simple app or minimal team structure. Xcodegen uses YAML for its specification structure — if you prefer a simpler static config format, it’s the right choice. For a broader look at both tools, see [How to automate iOS development](/articles/ios-automation/). | ||
| This is where a tool which creates the Xcode project is most helpful. There’s 2 leading tools which I’d recommend: Xcodegen or Tuist. [Xcodegen](https://github.com/yonaskolb/xcodegen) is great if you have a fairly simple app or minimal team structure. Xcodegen uses YAML for its specification structure — if you prefer a simpler static config format, it’s the right choice. For a broader look at both tools, see [How to automate iOS development](/articles/ios-automation/). | ||
|
|
||
| Tuist is what I’d recommend in most any other case. Tuist uses Swift for its manifest files, which is a deliberate design choice — it gives you type-checking and the full power of the language for complex configurations. Tuist has a very robust community and support as well. In the end I’d highly recommend **not** committing Xcode projects to your code repository. | ||
| [Tuist](https://tuist.dev) is what I’d recommend in most any other case. Tuist uses Swift for its manifest files, which is a deliberate design choice — it gives you type-checking and the full power of the language for complex configurations. Tuist has a very robust community and support as well. In the end I’d highly recommend **not** committing Xcode projects to your code repository. |
There was a problem hiding this comment.
Polish intro copy for clarity and correctness.
There are a few user-facing text issues in this edited block (eleviated, “There’s 2”, and “most any”) that read as errors in published content.
Suggested copy edit
-The Xcode project uses a _proprietary format_ that is notoriously difficult to work with, especially when dealing with merge conflicts in version control. In the ancient days, it was Storyboards and Xcode projects which were the biggest culprits of merge conflict hell. Coding your UI in UIKit and then SwiftUI eleviated the Storyboard issue but Xcode projects still remain.
+The Xcode project uses a _proprietary format_ that is notoriously difficult to work with, especially when dealing with merge conflicts in version control. In the past, Storyboards and Xcode projects were the biggest culprits of merge-conflict pain. Coding UI in UIKit and later SwiftUI alleviated many Storyboard issues, but Xcode projects still remain.
-This is where a tool which creates the Xcode project is most helpful. There’s 2 leading tools which I’d recommend: Xcodegen or Tuist. [Xcodegen](https://github.com/yonaskolb/xcodegen) is great if you have a fairly simple app or minimal team structure. Xcodegen uses YAML for its specification structure — if you prefer a simpler static config format, it’s the right choice. For a broader look at both tools, see [How to automate iOS development](/articles/ios-automation/).
+This is where a tool that generates the Xcode project is most helpful. There are two leading tools I recommend: Xcodegen and Tuist. [Xcodegen](https://github.com/yonaskolb/xcodegen) is great for a fairly simple app or a smaller team structure. Xcodegen uses YAML for its specification format — if you prefer a simpler static config, it’s the right choice. For a broader look at both tools, see [How to automate iOS development](/articles/ios-automation/).
-[Tuist](https://tuist.dev) is what I’d recommend in most any other case. Tuist uses Swift for its manifest files, which is a deliberate design choice — it gives you type-checking and the full power of the language for complex configurations. Tuist has a very robust community and support as well. In the end I’d highly recommend **not** committing Xcode projects to your code repository.
+[Tuist](https://tuist.dev) is what I’d recommend in almost any other case. It uses Swift for manifest files, which is a deliberate design choice — you get type-checking and the full power of the language for complex configurations. It also has a robust community and strong support. In the end, I highly recommend **not** committing Xcode projects to your repository.🧰 Tools
🪛 LanguageTool
[grammar] ~15-~15: Ensure spelling is correct
Context: ...oding your UI in UIKit and then SwiftUI eleviated the Storyboard issue but Xcode projects...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[style] ~19-~19: Avoid the colloquial phrase ‘most any’ in formal writing. Use “almost any” instead.
Context: ...s://tuist.dev) is what I’d recommend in most any other case. Tuist uses Swift for its ma...
(MOST_EVERYONE)
[style] ~19-~19: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...he language for complex configurations. Tuist has a very robust community and support...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Content/tutorials/tuist-xcode-project-setup.md` around lines 15 - 19, Fix the
three user-facing copy issues in the paragraph: replace "eleviated" with
"alleviated", change "There’s 2 leading tools" to "There are two leading tools",
and change "most any case" to "most cases" (or "most other cases"); ensure the
surrounding sentences read smoothly and keep emphasis on not committing Xcode
projects to the repo. Update the strings in the
Content/tutorials/tuist-xcode-project-setup.md block containing those phrases.
Comment on lines
+1319
to
+1320
| @apply whitespace-pre-wrap text-xs font-extralight p-4 bg-gray-900 text-white block my-4 lg:text-base lg:p-8; | ||
| overflow-x: auto; |
There was a problem hiding this comment.
Fix stylelint failure on declaration spacing.
Line 1320 needs an empty line before overflow-x: auto; to satisfy declaration-empty-line-before.
Suggested fix
pre code {
`@apply` whitespace-pre-wrap text-xs font-extralight p-4 bg-gray-900 text-white block my-4 lg:text-base lg:p-8;
+
overflow-x: auto;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| @apply whitespace-pre-wrap text-xs font-extralight p-4 bg-gray-900 text-white block my-4 lg:text-base lg:p-8; | |
| overflow-x: auto; | |
| `@apply` whitespace-pre-wrap text-xs font-extralight p-4 bg-gray-900 text-white block my-4 lg:text-base lg:p-8; | |
| overflow-x: auto; |
🧰 Tools
🪛 Stylelint (17.9.0)
[error] 1320-1320: Expected empty line before declaration (declaration-empty-line-before)
(declaration-empty-line-before)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Styling/styles/styles.css` around lines 1319 - 1320, The stylelint failure is
caused by missing empty line before the declaration `overflow-x: auto;`; edit
the CSS rule that contains the `@apply whitespace-pre-wrap ...` declaration and
insert a single blank line immediately before the `overflow-x: auto;` line so
there is an empty line between the `@apply ...;` statement and the `overflow-x`
declaration to satisfy the `declaration-empty-line-before` rule.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by CodeRabbit
Documentation
Bug Fixes
Chores