@gtomitsuka Thank you!! If you're interested; I once did a very brief attempt at moving the remaining cli/winresources package to their individual cmd/xxx sub packages. I was hoping that to be not too complicated, but it looks like there were still some things to untangle (so that still required work)

My draft PR with that first attempt is #46886 (I just rebased it); feel free to take that branch if you're interested on working on that (and if my branch is useful 😄).

@thaJeztah thanks for rebasing, I'll look into it this weekend!

Thanks! And don't feel "required" to do so, but it's just one of those patches that are in the back of my head and "I need to spend some time making it work". In all honesty, I'm not too familiar with that code, so I would have to do some digging (and your guess is probably as good as mine!).

I can list some quick thoughts;

• Goal is to get rid of that CLI package (as it's really no longer needed)
• With the ongoing effort of (one day!) being an actual go module, we want to better organise the code (separate things we expect to be consumed from "binary" code - only used to build the engine itself); possibly this could involve multiple modules, but those can be a bit of a pain, so that's still somewhat "TBD"
• For the PR linked above; if that means duplicating some files (icon files, manifest-templates) for better separation; that's perfectly acceptable
• If moving the code works; that's good, but we're also not "tied" to the implementation; ISTR the CLI uses a different utility for the winresources; if that's indeed the case, and if that implementation is better to use, we can consider switching (but that could also be in a follow-up after); https://github.com/docker/cli/tree/925e7d687045ea0c5a674c830762b7787c3253b1/cli/winresources

@crazy-max did some of the work on these, and if needed may be able to provide more input 🙈 (sorry for the ping, Kevin!)