liamnichols / xcstrings-tool

A plugin to generate Swift constants for your Strings Catalogs.

Home Page:https://swiftpackageindex.com/liamnichols/xcstrings-tool/documentation/documentation

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Unable to compile for tests

tyiu opened this issue · comments

I'm able to build and run just fine with this tool and it works great! But I can't get it to compile for tests.

Here's the commit I'm working on:
tyiu/nos@d3aee1d

Screenshot 2023-12-14 at 11 31 32 AM

Any ideas? Thank you!

Hey, that is a strange error.. in this instance, is the ExpirationTimeOption.swift file part of the test target or the app target?

The error mentions that String.LocalizationValue doesn’t have the localizable member, which is true, because localizable is available on an extension of LocalizedStringResource.

Without seeing the code/setup in more detail it is hard to say, but if this file is in your tests, are you sure that the right method that accepts LocalizedStringResource is available in your test code?

I’m just clicking through on my phone now so I couldn’t navigate the linked commit, but I’ll take more of a look tomorrow if you are still having issues

Hey, that is a strange error.. in this instance, is the ExpirationTimeOption.swift file part of the test target or the app target?

ExpirationTimeOption.swift and a few other files that were showing the error are part of both the app target and test target.

The error mentions that String.LocalizationValue doesn’t have the localizable member, which is true, because localizable is available on an extension of LocalizedStringResource.

Without seeing the code/setup in more detail it is hard to say, but if this file is in your tests, are you sure that the right method that accepts LocalizedStringResource is available in your test code?

It should be available. I'm just calling String(localized: .localizable.myStringKey), which is part of Foundation.

I’m just clicking through on my phone now so I couldn’t navigate the linked commit, but I’ll take more of a look tomorrow if you are still having issues

I appreciate it. Thank you!

ExpirationTimeOption.swift and a few other files that were showing the error are part of both the app target and test target.

Hmmm, this might be the issue.

The generated code will be generated in your app target with the internal access level, so your test target wouldn’t see this.

You would need to @testable import the app target in your test target code in order to see it, or alternatively you could opt to generate the code with the public access level.

But I don’t think that either of these options will work alone if you are just reusing the same file in two targets.

Perhaps in a different file in your test target, you might be able to re-export the accessor? I haven’t tried, but something like this:

import Foundation 
@testable import struct MyTarget.LocalizedStringResource.Localizable

extension LocalizedStringResource {
    static let localizable = Localizable()
}

I haven’t tried this though, but the goal is to make that generated code visible to the test target

ExpirationTimeOption.swift and a few other files that were showing the error are part of both the app target and test target.

Hmmm, this might be the issue.

The generated code will be generated in your app target with the internal access level, so your test target wouldn’t see this.

You would need to @testable import the app target in your test target code in order to see it, or alternatively you could opt to generate the code with the public access level.

But I don’t think that either of these options will work alone if you are just reusing the same file in two targets.

Perhaps in a different file in your test target, you might be able to re-export the accessor? I haven’t tried, but something like this:

import Foundation 
@testable import struct MyTarget.LocalizedStringResource.Localizable

extension LocalizedStringResource {
    static let localizable = Localizable()
}

I haven’t tried this though, but the goal is to make that generated code visible to the test target

What you suggested didn't work, but I finally fixed it by adding the *.xcstrings files to the test target, and adding the plugin to the build phase of the test target. Which in hindsight was obvious. Thanks for helping me debug! Loving the plugin. Keep it up.

No worries, I'm glad that you found a workaround!