Fix integration of SPM packages with slashes in their targets names

[kapitoshka438]

Resolves #6145

Short description 📝

Although targets names and bundle identifiers have to be Uniform Type Identifiers, SPM is able to process some non-compliant targets such as those that contain a slash "/" in their name just by replacing it with an underscore "_".
This PS brings the same to enable Tuist to work with dependencies like KSCrash.

How to test the changes locally 🧐

KSCrash was added as an SPM dependency in the app_with_spm_dependencies fixture.

Contributor checklist ✅

• The code has been linted using run mise run lint:fix
• The change is tested via unit testing or acceptance testing, or both
• The title of the PR is formulated in a way that is usable as a changelog entry
• In case the PR introduces changes that affect users, the documentation has been updated

Reviewer checklist ✅

• The code architecture and patterns are consistent with the rest of the codebase
• Reviewer has checked that, if needed, the PR includes the label changelog:added, changelog:fixed, or changelog:changed, and the title is usable as a changelog entry

[danibachar]

I think the same happens with whitespaces - example package.
https://github.com/Shopify/mobile-buy-sdk-ios

[fortmarek]

Thanks a lot for the PR, a couple of comments, but nothing major 🙂

[fortmarek]

I would probably hardcode this. The less business logic in tests the better.

Suggested change

	let expectedBundleName = "\(projectName)_\(sanitizedTargetName)"
	let expectedBundleName = "sdk_with_dash_target_with_dash"

[fortmarek]

Shouldn't the sanitize method already do the replacement?

[fortmarek]

Given in how many places we needed to update this, I wonder if we should extract this into a helper method such as:

extension TuistGraph.Target {
  static func sanitizedTargetName(_ targetName: String) -> String { ... }
}

[kapitoshka438]

@fortmarek I've rebased and made some fixes. Still have no idea what's happening on CI tho. All tests pass fine locally.

[fortmarek]

I've rebased and made some fixes. Still have no idea what's happening on CI tho. All tests pass fine locally.

main seems to be green the couple of last commits. Afaict tell from the test results, this is likely related to your PR. Both tests fail with the same crash:

• 1E8485E6-C7B2-4CEB-85D1-139EF478774D-processed copy.txt

The main part of the crash is TuistAutomationAcceptanceTests 0x108191590 UNIXPath.appending(component:) + 528. Is it possible that we're adding an invalid component somewhere in the test that causes things to crash?

[kapitoshka438]

I've rebased and made some fixes. Still have no idea what's happening on CI tho. All tests pass fine locally.

main seems to be green the couple of last commits. Afaict tell from the test results, this is likely related to your PR. Both tests fail with the same crash:

• 1E8485E6-C7B2-4CEB-85D1-139EF478774D-processed copy.txt

The main part of the crash is TuistAutomationAcceptanceTests 0x108191590 UNIXPath.appending(component:) + 528. Is it possible that we're adding an invalid component somewhere in the test that causes things to crash?

Yay thank you @fortmarek this helped a lot.
I don't know why but this assertion was commented out for me locally.
I've pushed fixes, CI finally passed

[fortmarek]

Great findings @kapitoshka438 👏

[TopIvanAbramov]

@fortmarek when can we expect to see this bugfix in release and which version?

[fortmarek]

when can we expect to see this bugfix in release and which version?

We try to release weekly on Monday, i.e., there should be 4.14.0 tuist release on Monday.