Choice of placement/naming of Project.swift

This file seems to be generated at the top-level of each project. I run into an issue with that (it has a workaround that is sub-optimal).

The issue is that I also like to “SwiftLint” at this same directory level (so it finds both sources and tests). This of course causes the Project.swift file to be listed and it will, most likely, not be compliant with whatever rules a user has setup SwiftLint with.

The workaround is to put “Project.swift” on the excluded list for SwiftLint. For my current project(s) that works just fine, but if one would ever have a file with a similar name as part of their source tree, it would also be excluded, which is undesirable.

I can see two options:

  1. Give this file a much more distinct name, e.g. “TuistProject.swift”. It does not remove the issue, but it makes collisions much less likely and it would be safer to exclude that name
  2. Place the file somewhere else. This would have to be a designated sub-directory of the project folder. Many names for that could be chosen…

Of course if either of the changes would be made, backward compatibility would dictate that the current mode of operation also works.

This is an interested use-case we did not think about. What I had in mind was building a tuist lint command that would do the filtering for you automatically. Do you think that something like this would help? Changing the name of the manifest file, or being opinionated about the location of those files would be an important change for Tuist that I’d avoid unless there’s a very good reason for it.

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 TuistProject.swift and TuistSetup.swift
  • This convention would allow an exclude “glob” for names starting with “Tuist” or might explicitly list these two files
  • During 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
  • During 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).