The package acess level used on '...' requires a package name;

[sobabear]

Describe the bug 🐛

I've got build error with above image. /OneWay/Store.swift:43:5 The package access level used on 'isIdle' requires a package name; set it with the compiler flag -package-name

/OneWay/Sources/OneWay/ViewStore.swift:44:5 The package access level used on 'store' requires a package name; set it with the compiler flag -package-name

To Reproduce ✨

1. Update to Xcode 16.0 (MacOS 14.5)
2. Installed Oneway 2.3.0 (Using tuist, .upToNextMajor(from: "2.3.0"))

Expected behavior 🌈

Build without errors

Environments ⚙️

• Mac OS: 14.5
• Device or Simulator OS: iphone 15(iOS 17.5.1) or simulator iphone15 (17.4)
• Xcode Version: Xcode 16.0
• Library Version: 2.3.0

[sobabear]

P.S. I am not considering this happens because of updating xcode, but i am guessing might be related to recent reslease(2.8.0). Not only my mac but on CI Mac(mini) also happens the issue since around 3~4 days ago when 2.8.0 had release

[DevYeom]

It seems that the issue occurred because Tuist regenerates the project without using native package. This appears to be a package access level support issue in Tuist. What version of Tuist are you using?

Related to https://github.com/tuist/tuist/issues/5970

[sobabear]

You are right I just checked, it isnt moduling using targets on xcode, especially tuist version is 3 (3.32.0)

[DevYeom]

There are three solutions:

• Upgrade the Tuist version to 4.4.0 or higher.
• Set the OneWay version exactly to 2.7.0.
  • .exact("2.7.0")
• Add the dependency as a native package in the Tuist manifests.

[DevYeom]

package access level was added in Swift 5.9, so I would recommend to keep your project up to date.

Thanks for reporting!

[sobabear]

I got to use current tuist version for domestic issue for a while, but i might handle oneway version or using custom by fork...

Thanks for rapid answer thanks!

[DevYeom]

I will also consider alternative methods to replace the package access level.