Development/watch command for re-generating resources on the fly

[zdnk]

Context 🕵️‍♀️

With addition to synthesised resource accessors to Tuist, it would be awesome to also support some way the resources can be synthesised without regenerating and re-opening the whole project or workspace.

What 🌱

At the moment whenever I update string files or asset catalog I need to execute tuist generate to update generated Swift accessor to those resources. This means closing Xcode project, re-generating, opening Xcode project. Xcode checks SPM packages, starts indexing etc. Very annoying.

Proposal 🎉

Introduce Tuist Development mode. Tuist will watch resource directories and files for changes and regenerates accessors on the fly. I can imagine tuist dev, tuist development or tuist watch indefinitely running command.

[fortmarek]

Hi @zdnk, I agree it is not ideal to have to regenerate a project, especially early in the project's lifecycle.

This has also been proposed in Slack by @fila95 in a somewhat similar fashion. Rather than adding a watcher, I'd rather keep it simpler and create tuist synthesize command that would generate the accessors. Since this command would not modify .xcodeproj at hand, we'd also have to show a warning that you need to regenerate a project.

I think that a watcher should rather be implemented via a plugin, right now I am working on the possibility of adding custom tasks which would enable this.

What, I think, we should do first, though, is to look into why regenerating project with .xcworskpace cannot be done with Xcode opened. If you do this with .xcodeproj only, this works. @kwridan do you have any idea why that might be the case? It'd be quite a productivity boost to fix this.

[zdnk]

I see. Let me know if I can help in any way :)

Since this command would not modify .xcodeproj at hand, we'd also have to show a warning that you need to regenerate a project.

Why would we need to regenrate .xcodeproj? It would be great if Tuist created all the files needed for accessors even they'd be empty. That way you would never need to re-generate the project, right?

If you do this with .xcodeproj only, this works.

Are you sure? In our project Xcode always shows reload from disk or using current version dialog when we regenerate project with Xcode open. Sorry, I thought we have project, but for some reason Tuist is generating workspace.

[ferologics]

My 2 cents here -- using tuist generate --project-only still leads to the Build operations are disabled: 'project.xcworkspace' has changed and is reloading. error even if there_is_no_actual .xcworkspace in project root directory. Which confirms that the error is about the nested App.xcodeproj/project.xcworkspace :confused:

[ferologics]

Reposting a "workaround" script for project re-generation-opening that got posted in associated slack discussion (kuddos to @fortmarek -- and his coworker -- whoever it may be 😅)

alias tg="osascript -l JavaScript -e 'function run(a){Application(\"Xcode\").workspaceDocuments().forEach(d=>{if(d.path().includes(a))d.close()})}' $(pwd); tuist generate; xed -b ."

[ferologics]

If anyone is a fish shell user I modified the above script:

function tg
  set close_window 'tell application "Xcode" to close window 1'
  osascript -e $close_window
  tuist generate --project-only --open
end

[ferologics]

@zdnk does the 1.41.0 release resolve your issue? You should be able to keep your project/workspace open while running the tuist generate command 🙂

[zdnk]

It does not really, it changes nothing about the fact when I fetch new localization files or add/remove asset, I have to manually regenerate the project. The issue is having to do it manually every time anything changes.

Otherwise, yes, right now I am able to regenerate the project/workspace without Xcode complaining while open :)

[ferologics]

I see, that seems like the natural next step to take! This tuist dev command could cache output of tree . that can be diffed against the most recent snapshot (t-1) and if change is detected it would call to tuist generate 💡

[fortmarek]

This would be great, indeed! But maybe the implementation could be in a form of a plugin and run from Tasks.swift (PR here) - I think this command is general enough (and should be flexible enough) that there is not necessarily a need for it to live in the core repository.

[zdnk]

It would also make sense to regen just the Swift accessors for the properties instead of the whole project as it is more time consuming operation.

[pepicrft]

Here are some ideas:

• Have a running command that re-generates the synthesized accessors when resources change. I don't like from this one that you need to remember that there's a process running in the terminal.
• Add a new command, tuist build-phase that is run from a build phase on the target. I'd make this an opt-in feature because it couples the generated Xcode project to Tuist. When enabled, the build phase will call Tuist, and Tuist will generate the interfaces as part of the build process.

[danieleformichelli]

What about adding a flag to tuist generate that just generates the accessors? Or maybe a separate command but I don't think it's worth to add one just for that 🤷

[mgray88]

tuist generate derived? Since that's the folder they end up in, that's the first thing I'll think of when trying to remember what to type. User intuitive

[pepicrft]

What about adding a flag to tuist generate that just generates the accessors? Or maybe a separate command but I don't think it's worth to add one just for that 🤷

I'm more inclined towards this one. Perhaps tuist generate --only-resource-synthesizers

[jesus-mg-ios]

Hi community, I'm trying to develop this, but I'm lost in this large amount of mappers generators etc ... At the moment I added a flag to the generate command, but I'm not sure what to exclude of execute when this flag is passed as command-line argument.

Could Someone help me with the task? I don't know if you @danyf90 can give me a clue.

Thank you in advance

[danieleformichelli]

Not 100% sure, but it might be enough to load the graph and then fed it to the ResourcesProjectMapper, something like:

        let (graph, sideEffects) = try await load(path: path)

        // Load
        let graphTraverser = GraphTraverser(graph: graph)

        foreachproject {
          resourceMapper.map($0)
        }

[enlivn]

Is it possible to add a note about this to https://docs.tuist.io/guides/resources/#resourcesynthesizers? It's not clear that this is a limitation. I'm happy to PR that in if you like.

[fortmarek]

Is it possible to add a note about this to https://docs.tuist.io/guides/resources/#resourcesynthesizers? It's not clear that this is a limitation. I'm happy to PR that in if you like.

That'd be great, feel free to do so 🙌

[enlivn]

@fortmarek sorry, I didn't get pinged and just saw this in my Github notifications. I'll put a PR up in a couple days.

[enlivn]

@fortmarek I've put up PR #4868 with the documentation update.

[thebarndog]

Has there been any movement on this with the later versions of Tuist? It's by far the biggest pain point I face when using Tuist solely because of how often I have to drag in or change resources and having to run tuist generate every single time is not great.

[danieleformichelli]

Nope, unfortunately it hasn't been implemented yet