feat: add spm-migration-assistant cli command

[markemer]

[jcesarmobile]

Another thought, since it doesn't do a full migration, maybe it should be renamed to assist-spm-migration?

And at the end it should show a link to the SPM docs, to the ### Using our migration tool section once it's live.

[markemer]

Added some comments.

Also:

• ios-spm-template already has the same files you created in the ios-spm-migrate-template, can't you use ios-spm-template files instead of a new ones?
• Do we need the --unsafe and --dry-run options? for --unsafe I assume people uses git or some other source control, so they could revert if they had some problem. And for --dry-run we are documenting the changes the command does so people can know.
• We have a separate ticket for the messaging/handling of non SPM plugins, so you can leave those changes out of the migration command.

• I can look into the best way to use the template files - it might be trivial to do that.
• I'm gonna ditch --unsafe but keep --dry-run, I think
• Non SPM plugins will just throw a warning for now - but I don't want to give people the idea it worked when it didn't.

[markemer]

Added some comments. Also:

• ios-spm-template already has the same files you created in the ios-spm-migrate-template, can't you use ios-spm-template files instead of a new ones?
• Do we need the --unsafe and --dry-run options? for --unsafe I assume people uses git or some other source control, so they could revert if they had some problem. And for --dry-run we are documenting the changes the command does so people can know.
• We have a separate ticket for the messaging/handling of non SPM plugins, so you can leave those changes out of the migration command.

• I can look into the best way to use the template files - it might be trivial to do that.
• I'm gonna ditch --unsafe but keep --dry-run, I think
• Non SPM plugins will just throw a warning for now - but I don't want to give people the idea it worked when it didn't.

So the npm tar package seems not to respect the file list you give it. I even enumerated every file, so I think the separate tarball works better - although we could at some point generate it directly from the template directory.

[jcesarmobile]

So the npm tar package seems not to respect the file list you give it. I even enumerated every file, so I think the separate tarball works better - although we could at some point generate it directly from the template directory.

I don't understand what you mean in the comment, but can't you extract it to a temp folder and copy the needed files to the user project? I really don't want a separate template with duplicate files we have to maintain

[markemer]

So the npm tar package seems not to respect the file list you give it. I even enumerated every file, so I think the separate tarball works better - although we could at some point generate it directly from the template directory.

I don't understand what you mean in the comment, but can't you extract it to a temp folder and copy the needed files to the user project? I really don't want a separate template with duplicate files we have to maintain

Yeah, /tmp might be the way - tar should allow me to just untar the stuff I want - extract accepts a file list, but it seems to totally ignore it.

[markemer]

There are several comments that have not been addressed yet

I just pushed the removal of Cap-SPM as a separate zip file, should be ready now.

[markemer]

The Package.swift detection is not working properly, I get

Found 6 Plugins with Package.swift files: @capacitor-community/[email protected]

and then

[warn] CapacitorCommunityTapJacking does not have a Package.swift

Yeah, that's a new one on me - I'll take a look at why that's failing. The rest are no problem.

Also, can you remove the comments about you hating things?

Oh yeah, I didn't even mean to check that in. Moment of frustration with TS and all that.

Since I'm in here, I'll also change the name - it's gotten far enough away that I think you're right and I'm gonna call it spm-migration-assistant

[jcesarmobile]

The xcconfig file is being copied to ios/App/debug.xcconfig, but on the spm template it's located at ios/debug.xcconfig, so should be adjusted to match.

Also the incompatible plugin shows the plugin name instead of the id, i.e. CapacitorPluginSomething instead of @capacitor/something, the compatible plugins show the id.

[markemer]

Some messages use logger.info and other use logOptSuffix for the actions taken, they should all use the same. I don't really see the usefulness of the --dry-run, but if you want to add it, it should be consistent.

Maybe I should ditch dry-run, it's seeming less and less useful.

I have mentioned in previous reviews that the handling of the plugins shouldn't be part of this PR but the code is still here. The handling of the plugins should be done in the update command, not in the spm-migration-assistant because this is only ran once, so running update later on will bring back the plugins that were removed by this command. If you want to list the incompatible plugins in this command too you can programmatically call update at the end of the migration process. But the handling of the Package.swif and the incompatible plugins should be done in the update and not in this command. It's listing the plugins twice, it should do the listing only once but warning about the plugins that are not compatible.

Ah, ok, I was misunderstanding. Yeah - that logic should be moved and we can just run an update.

Also we discussed in slack about the possibility of patching incompatible plugins instead of removing them, did you take a look at that? would be cool to include it.

This was something we brought up a while back and thought about not adding, but I was always pro the idea of adding it.

As for the TODO I ditched - maybe we should try and tackle all the manual steps. We'd have to include either cordova-node-xcode or something else, but it might be worth it.

[markemer]

Why did you change the ios-spm-template? In my comment I meant to make your code match the template, not to make the template match your code. The template changes have been released in 7.3.0, so we shouldn't change it again in 7.4.0 or we will have users with different templates and if we can get rid of the debug.xcconfig file in the future we will have to document all the different locations, so better keep only one.

I actually changed both to fit the typical iOS pattern, but since we released 7.3.0 with it as is, I'll roll my changes back and just change the migration.