If you mean that this
tuist lint command would do something like run SwiftLint for you, I’m not sure I agree (there also already seems be a
tuist lint command which does something else). The potential problem with such an approach is lack of control. Similar to your carthage support right now in
tuist up. If I want to run carthage with a changed toolchain, which seems possible outside of Tuist, I cannot really do it because it requires tuist changes. Those may eventually come, but in the mean time one is stuck and has to do things manually. I’ll give an example below how I invoke SwiftLint that would not easily be supported this way.
Manually works, but diminishes the value of Tuist for that aspect. Something like SwiftLint has tons of options and ways of configuring the configuration files etc. Additionally, I like to run it as a build step, and that step does not involve tuist.
I understand the reluctance to change tuist file locations and naming. On the other hand, this is easier earlier in the project’s history than later. Making improvements to the usage model will help expand the user base. I would suggest the change(s) can be made without affecting the existing model:
- Let’s assume, for a minute, the “new” name(s) becomes
- This convention would allow an exclude “glob” for names starting with “Tuist” or might explicitly list these two files
tuist edit while building the editing project look for files with both old and new names.
- When both type names are found in the same location, prefer the new naming convention and ignore the old file
tuist generate and generating in a “clean” directory (no Tuist files present, old style, or new style), generate using the new names. If Tuist files are present, old style or new style, generate using whatever style is in use
- If, during
tuist edit or
tuist generate old style files are found, output a warning/suggestion to rename to newer stye
- Changing locations is also possible while keeping the old-style working, but I think just changing names would be enough.
- This is not because I am opinionated about this. I think I have identified a relevant concern (name collisions with actual project source files) and a means of reducing the odds of that happening for the user. This increases the value of Tuist not just to me…
How I SwiftLint:
I want a single .swiftlint.yml file to apply to my whole project, which means I want to place it in the
Projects directory. However, I want to run SwiftLint at the end of the build phase from a run script. That means when it is executed the working directory will be that of the individual (sub)project. SwiftLint does not look “upwards” to find a .swiftlint file. I could add code to the unscript (shell script) to “find” the correct configuration file and pass its location using the
--config option. This is, in fact, what I do and it works fine (its a complication I could do without and I think SwiftLint should support this, but that’s another story).