Support none defaultSettings

[pepicrft]

Short description 📝

Pairing with @RomainBoulay on porting a project to Swift, we figured out that there's no way to disable the generation of build settings by Tuist.

Solution 📦

I'm adding a new DefaultSettings case, .none, to disable the default build settings generation.

Implementation 👩‍💻👨‍💻

• Add DefaultSettings.none.
• Add tests.
• Update documentation.
• Update CHANGELOG.

[codecov]

Codecov Report

Merging #395 into master will increase coverage by 0.03%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #395      +/-   ##
==========================================
+ Coverage   92.19%   92.22%   +0.03%     
==========================================
  Files         291      291              
  Lines       14615    14673      +58     
==========================================
+ Hits        13474    13532      +58     
  Misses       1141     1141

Impacted Files	Coverage Δ
Sources/TuistGenerator/Models/Settings.swift	100% <ø> (ø)	⬆️
Tests/TuistGeneratorTests/Models/TargetTests.swift	98.88% <100%> (ø)	⬆️
...uistGeneratorTests/Utils/SettingsHelperTests.swift	100% <100%> (ø)	⬆️
...stGenerator/Settings/DefaultSettingsProvider.swift	100% <100%> (ø)	⬆️
...rTests/Settings/DefaultSettingsProviderTests.swift	100% <100%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 41c36d5...3bc640d. Read the comment docs.

[pepicrft]

@marciniwanicki / @kwridan I have the feeling there's already a way to achieve this but I couldn't find anything.

[tuistbot]

	1 Warning
⚠️	Have you introduced any user-facing changes? If so, please take some time to update the documentation. Keeping the documentation up to date makes it easier for users to learn how to use Tuist.

Generated by 🚫 Danger

[kwridan]

yikes, looks like we're missing exposing .none in the ProjectDescription

[kwridan]

Worth adding a warning style comment for the .none case highlighting Tusit is delegating the responsibility of settings to the user and the project may fail to compile! :)

[kwridan]

How does this look?

Projects may fail to compile if some essential settings are missing. Use .none only if you are specifying all the necessary build settings manually or via xcconfig files.

[pepicrft]

Something like this @kwridan ?

[kwridan]

Pushed an update to expose .none.

There are still some settings that get generated by Tuist - all the ones within https://github.com/tuist/tuist/blob/master/Sources/TuistGenerator/Generator/ConfigGenerator.swift#L156 - those are essential to Tuist's functionality (e.g. ensuring Test hosts are setup etc...) - perhaps to allow user control over some of those, we can change the order of precedence

• Set defaults
• Apply target derived settings
• Apply custom user specified settings

[pepicrft]

those are essential to Tuist's functionality (e.g. ensuring Test hosts are setup etc...) - perhaps to allow user control over some of those, we can change the order of precedence

Isn't that the current order? I think it makes sense to keep Tuist's derived settings because we infer those from the manifest. We could allow the user to control them but if things don't work, they'll blame Tuist for that.