Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SPM Prep – Define new CoreAPI package #782

Merged
merged 12 commits into from
Apr 16, 2024
Merged

Conversation

mokagio
Copy link
Contributor

@mokagio mokagio commented Apr 8, 2024

Description

Moves some of the lower level Swift files that implement API requests into Sources/CoreAPI with matching tests.

Getting the tests to compile in this setup required some additional work in terms of conditional imports and an SPM-aware Bundle loader.

Notice that the package exists but is not used anywhere. I just wanted to lock this in, so to speak, to build on top of it later on.

Testing Details

See CI. Although, it only shows that no regression has been introduced by this setup.

To test the SPM setup alone, one needs to:

  1. Delete the .xc- workspace and project folder
  2. Test via xcodebuild, for example with a lane like this one:
    lane :package_build do
    scheme = 'WordPressKit-Package'
    # We need to explicitly step the derived data folder, otherwise we'll get errors like:
    # > Cannot find .xcresult in derived data which is needed to determine test results.
    derived_data_path = File.join(__dir__, '.build', 'derived-data')
    xcodebuild(
    scheme:,
    xcargs: "-resolvePackageDependencies #{SWIFTLINT_PLUGIN_VALIDATION_BYPASS_XCARGS} -derivedDataPath #{derived_data_path}"
    )
    run_tests(
    package_path: '.',
    scheme:,
    device: 'iPhone 15',
    prelaunch_simulator: true,
    xcargs: SWIFTLINT_PLUGIN_VALIDATION_BYPASS_XCARGS,
    derived_data_path:
    )

OR

  1. Open the project in Xcode via Package.swift (open -a /Applications/Xcode.app . should do it)
  2. Run the tests

  • Please check here if your pull request includes additional test coverage. — N.A.
  • I have considered if this change warrants release notes and have added them to the appropriate section in the CHANGELOG.md if necessary. — N.A.

@dangermattic
Copy link
Collaborator

2 Warnings
⚠️ Package.swift was changed without updating its corresponding Package.resolved. Please resolve the Swift packages in Xcode.
⚠️ This PR is larger than 300 lines of changes. Please consider splitting it into smaller PRs for easier and faster reviews.

Generated by 🚫 Danger

Comment on lines +66 to +71
// When building for SPM, the compiler doesn't generate the domain constant.
#if SWIFT_PACKAGE
XCTAssertEqual(error.domain, "CoreAPI.WordPressOrgXMLRPCApiError")
#else
XCTAssertEqual(error.domain, WordPressOrgXMLRPCApiErrorDomain)
#endif
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@crazytonyli what do you think of this?

I worry it might backfire in the real world if people where to do a comparison on the domain with a String literal value.

Maybe it would be safer to explicitly define the domain in a let and update the code that inits WordPressOrgXMLRPCApiError to set it?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My preference would be going with the safer option, which is avoiding breaking changes. You can implement CustomNSError to set a custom domain, which means we shouldn't need to change this assertion here.

Copy link
Contributor Author

@mokagio mokagio Apr 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Partially addressed in 3f57895.

However, the tests still fail when build for SPM. I believe that has to do with the XML RPC returning WordPressOrgXMLRPCApiError or WordPressOrgXMLRPCApiFault.

I'll have to look into the latter as well, I guess.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found the source of the issue.

If one removes the @objc annotation, then the CustomNSError conversion code is used in its entirety. Otherwise, with the error enum declared as @objc, it seems like only the part that computes userInfo is called.

I verified this with an ad hoc package. I might put it online later. I'm unsure how to move forward in the meantime, because we do need the @objc visibility for WordPressOrgXMLRPCApiError. I'll keep thinking about it...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Move my WIP work to #790 and rebased it off this branch.

WPKitLogVerbose("Received OAuth2 response: \(self.cleanedUpResponseForLogging(responseObject as AnyObject? ?? "nil" as AnyObject))")
// WPKitLogVerbose("Received OAuth2 response: \(self.cleanedUpResponseForLogging(responseObject as AnyObject? ?? "nil" as AnyObject))")
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might need to introduce a new abstraction layer for logging, too.

Or, is logging at this level useful? Can we simply get rid of it altogether?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I opened an issue about it #787

@mokagio mokagio marked this pull request as ready for review April 11, 2024 23:34
@mokagio mokagio enabled auto-merge April 11, 2024 23:47
let WordPressComRestApiErrorDomain = "WordPressKit.WordPressComRestApiError"

// WordPressComRestApiErrorDomain is accessible only in Swift and, since it's a global, cannot be made @objc.
// As a workaround, here is a builder to init NSError with that domain and a method to check the domain.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An alternative could be defining the same constant again in Objective-C and making it unavailable to Swift. That way you won't need to change those Objective-C files.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See 6fba3a1

Comment on lines +66 to +71
// When building for SPM, the compiler doesn't generate the domain constant.
#if SWIFT_PACKAGE
XCTAssertEqual(error.domain, "CoreAPI.WordPressOrgXMLRPCApiError")
#else
XCTAssertEqual(error.domain, WordPressOrgXMLRPCApiErrorDomain)
#endif
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My preference would be going with the safer option, which is avoiding breaking changes. You can implement CustomNSError to set a custom domain, which means we shouldn't need to change this assertion here.

@mokagio mokagio force-pushed the mokagio/coreapi-package branch 2 times, most recently from 22dcdd8 to 7198442 Compare April 15, 2024 05:59
This DRYs the definition, makes the constant available to both
Objective-C and Swift, and removes the need for custom builder and
checker.

See @crazytonyli's suggestion from
#782 (comment)
@mokagio mokagio merged commit 7b624cd into trunk Apr 16, 2024
9 checks passed
@mokagio mokagio deleted the mokagio/coreapi-package branch April 16, 2024 16:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants