You're on fire! 👍
I'll take a look in the afternoon, thanks again!

My thoughts on your questions in your original comment:

Images

We'd only add an extra level if there are multiple catalogs.

Seems good to me. But be sure to make it as a separate key in the StencilContext, so that people would have the chose to separate it or not in their own templates.

That logic of adding an extra level should be done at the template level imho, with the StencilContext probably having a root key assetCatalogs containing an array of Dictionaries ((name, assets) pairs), one for each Asset Catalog with their name and content. And then the template would iterate over them; using the assetCatalogs[i].name or not in the template being up to the template itself, and using it only if assetCatalogs.count > 1 seems a good idea for the bundled templates.
(You might need to add an extra hasMultipleCatalogs: Bool root key to the StencilContext as I think it's not possible in Stencil to compare values using > 1 just yet?)

Colors

Colors being generated by a file entirely written manually (as opposed to other commands relying on parsing directories and Xcode/IB files), I'm not sure a lot of people have multiple colours input files 🤔

But since we'd probably already have the logic for the Images, it's probably worth doing the same logic for Colors indeed.

Strings

As you said, name spacing Strings is probably worth being in its own separate PR to handle tableNames.

• Images: agreed. I'd let it depend on Images: dot syntax #206 as it already has all the structure stuff, just add an extra enum case.
• Colors: that's what I though, but it has a bit more implications as right now, a color parser is a specific subclass for a specific file type. I'd need to create a more general color parser type, that internally creates the correct parsers for each file type.
• Strings: later.

Another thing that would be nice to add in this PR would be to generate an error in case the path(s) given to swiftgen images isn't an .xcassets directory. That way, people that used to do swiftgen images $(PROJECT_DIR) would now have an explicit error message rather than ending with #207

I'd actually put that in a separate PR, coming up!

Tried a rebase this time. Also tried it with #206 but that just gave me headaches 😐

Is this really done and ready to merge now? (I mean, for what I've reviewed in GitHub it seems OK to me, but given that the original comment of this PR still has unchecked boxes I don't want to merge on your behalf if you planned to add more to this PR or will do them in separate PRs.

But if you're good, I'll let you the pleasure of hitting the Merge button 👍

Ok. I just added the WIP label to mark it as unfinished, feel free to remove once ready 👍

Right, so images was a bit more annoying than expected.

Both images and strings dot-syntax should be rewritten with some sort of recursion using the set tag. I've noticed that the modified context is stack dependent, so if you set a variable inside an if block, it won't be visible outside of that block. Which is good news for recursion.

The current templates contains code that depends on unreleased Stencil code (stencilproject/Stencil#77), but compiles without issues for now. Multiple catalogs' entries will for now appear under one enum. Once we have the new Stencil, we can expect it to automatically work, and will just need an updated output file.

Does that mean that we should wait for the new version of Stencil containing stencilproject/Stencil#77 to be out to release a version of SwiftGen with this #213 PR? As otherwise we would do breaking changes twice (one with the images template containing the extra level even if there's only one assets catalog, then later the one removing it)?

I'm happy to make a Stencil 0.8 (or maybe 1.0-rc.1 🤔) release soon to support this if needed.

Yeah, I suggest waiting until we can merge a PR supporting the latest Stencil.

👍