I have a project with yarn (v1) workspaces.
project/
packages/
pkgA/
subPkgA1/
pkgB/
package.json has this:
"workspaces": {
"packages": [
"packages/pkgA",
"packages/pkgA/subPkgA1",
"packages/pkgB"]}
note that there's a nested workspace in there.
Top-level has jest#27.4.7 in its package.json.
pkgA has jest#24.9.0 because one of its dependencies requires that version; its package.json has no entry for jest.
pkgA/subPkgA1 has jest#27.4.7 in its package.json, BUT it actually gets 24.9.0 installed in its node_modules/.bin/jest, presumably because its parent workspace has that.
My main question is how to get jest#27.4.7 in the nested package subPkgA1? I tried adding an entry in pkgA's package.json, but that didn't help.
BTW, I know nested workspaces aren't fully supported until Yarn v2, but I can't upgrade right now, and I can't easily move my subpackage out of its parent, so any hacky solution would be better than nothing.
I have my projects that have many packages which import each other and import outside packages. When I make a change to one of my low lever packages, and then push it to git it is fine and works in that section. When I go get it for use in another project that was working perfectly I now get this go get this error:
module declares its path as: github.com/xdg-go/scram
but was required as: github.com/xdg/scram
None of my code uses either of those directly. It looks like it automatically updated some lower external packages and broke things the used to then old import.
How do I either find out the package that is importing the wrong name or stop all auto-updates?
The go.mod file at github.com/xdg/scram declares itself as github.com/xdg-go/scram:
module github.com/xdg-go/scram
go 1.11
require (
github.com/xdg-go/stringprep v1.0.2
golang.org/x/crypto v0.0.0-20210322153248-0c34fe9e7dc2
)
The go.mod file should be updated to reflect the correct import path.
Unfortunately if this module is for you an indirect dependency, the best fix possible is to update whatever project you import that is directly importing it.
When that is not an option, a solution to this error is to clone the problematic repository locally and use the replace directive in your go.mod file:
module mymodule
replace github.com/xdg/stringprep => ../strprep
go 1.16.2
require (
github.com/divjotarora/mgo v0.0.0-20190308170442-1d451d2a3149
)
where ../strprep is where the code of the required module exists in your local machine, relative to the go.mod file of your project.
The downside of this of course is that you have to replicate this palliative fix wherever you plan to go get your modules.
Note also:
divjotarora/mgo is just a random example of a project that imports one of those packages using their old import path.
I'm using xdg/stringprep as an example because I can't find modules that import xdg/scram instead, but apparently it suffers from the same issue
Beside, you can use:
go mod why <package> to find out why a certain package is listed as a dependency of your project
go mod graph to show the full dependency graph. The output is in <package> <requirement> format
I am having issues using google.golang.org/grpc from vendor directory and I get the below error
cannot use &metadata.HeaderMD (type *"google.golang.org/grpc/metadata".MD) as type *"project1/vendor/google.golang.org/grpc/metadata".MD in argument to grpc.Header
I get the error though I am using the necessary version of the package which I copied from my gopath. But, when I delete the golang.google.org/grpc folder from vendor my project fetches the dependency from gopath and it works fine though the one gopath is a copy of when I have in vendor directory and every other library in vendor directory works fine except grpc.
When you created project1/vendor/google.golang.org/grpc, it means that for packages under project1/..., an import of google.golang.org/gprc/... will be transparently remapped to the vendor version.
Any packages outside of project1 will continue to import the non-vendored google.golang.org/grpc/... packages. While the vendored package might be a copy of the upstream, Go treats them as independent packages. So the types they contain are not equivalent.
What has most likely happened is that one of your non-vendored dependencies imports the grpc package and uses its types in its public API. When you make use of that API from project1, you get the upstream type which can't be assigned to variables using the vendored types.
There's two possible solutions to this problem:
Vendor all of your dependencies that make use of what you've already vendored.
If you're using Go >= 1.11, switch to the newer Go module build system. This will let you continue to control when you upgrade your dependencies without having the project1/vendor/... tree to confuse the type system.
I'm running Xcode 11 Beta 4.
I'm using CocoaPods, and wanted to use one of my dependencies with Swift Package Manager as a static library instead of as a framework.
On a fresh project created with Xcode 11, the dependency can be imported successfully, but on my existing CocoaPods workspace, it does not.
I think it's likely related, but I'm also getting this link warning in Xcode:
directory not found for option '-L/Users/username/Library/Developer/Xcode/DerivedData/App-axanznliwntexmdfdskitsxlfypz/Build/Products/Release-iphoneos
I went to see if the directory exists after the warning is emitted, and it does.
I could not find any meaningful difference between the newly-created project and my old one, other than the existence of CocoaPods.
Would appreciate any pointers.
After adding a library (FASwiftUI in my case) through Swift Package Manager I had to add it to
Project Settings -> My Target ->
General -> Frameworks, Libraries, and Embedded Content
to be visible in the import statement.
I did not add any scripts for it to work.
Based on #AlexandreMorgado answer it seems like it is better to run this script in Build phases before Compile Sources. Then it works when archiving.
if [ -d "${SYMROOT}/Release${EFFECTIVE_PLATFORM_NAME}/" ] && [ "${SYMROOT}/Release${EFFECTIVE_PLATFORM_NAME}/" != "${SYMROOT}/${CONFIGURATION}${EFFECTIVE_PLATFORM_NAME}/" ]
then
cp -f -R "${SYMROOT}/Release${EFFECTIVE_PLATFORM_NAME}/" "${SYMROOT}/${CONFIGURATION}${EFFECTIVE_PLATFORM_NAME}/"
fi
Solution
let package = Package(
name: "PackageName",
dependencies: [
// YOU MUST ADD THE DEPENDENCY BOTH HERE [1] AND BELOW [2]
.package(url: "https://github.com/mattmaddux/FASwiftUI", from: "1.0.4")
],
targets: [
.target(
name: "PackageName",
/*[2]*/ dependencies: ["FASwiftUI"], // [2] <<<--------- Added here as well
]
)
Explanation
I'm developing a Swift package that must provide FontAwesome Icons to whoever imports it.
I was getting "No such module 'FASwiftUI'" in my SwiftUI preview canvas.
I solved it by adding "FASwiftUI" to BOTH the dependencies array of the package AS WELL AS to the dependencies array in the target itself.
Full Package.swift File
// swift-tools-version:5.3
// The swift-tools-version declares the minimum version of Swift required to build this package.
import PackageDescription
let package = Package(
name: "PackageName",
platforms: [
.macOS(.v11),
.iOS(.v14)
],
products: [
// Products define the executables and libraries a package produces, and make them visible to other packages.
.library(
name: "PackageName",
targets: ["PackageName"])
],
dependencies: [
// Dependencies declare other packages that this package depends on.
.package(url: "https://github.com/nalexn/ViewInspector", from: "0.8.1"),
.package(url: "https://github.com/mattmaddux/FASwiftUI", from: "1.0.4")
],
targets: [
// Targets are the basic building blocks of a package. A target can define a module or a test suite.
// Targets can depend on other targets in this package, and on products in packages this package depends on.
.target(
name: "PackageName",
dependencies: ["FASwiftUI"], // <<<--------- Added this here
resources: [
.process("Assets")
]
),
.testTarget(
name: "PackageNameTests",
dependencies: ["PackageName", "ViewInspector"])
]
)
It turned out that Swift Package Manager implicitly depends on the project's Configuration names. I had them at live/qa instead of Release/Debug, and changing them back resolved the issue. Very odd, but I hope it saves you some trouble dear reader.
After a whole week fighting this issue, I developed a workaround using schemes and pre-actions.
I have a configuration called "Beta", so Xcode can't compile SPM dependencies. I realised Xcode compile SPM dependencies as Swift modules and add the files in Build/Products/Release-iphoneos folder in DeriverData.
So I created a scheme in Xcode and added this run script on build pre-actions:
cp -f -R "${SYMROOT}/Release${EFFECTIVE_PLATFORM_NAME}/" "${SYMROOT}/${CONFIGURATION}${EFFECTIVE_PLATFORM_NAME}/"
This script run before the build process, copying files and modules generated by Xcode on default Release-iphoneos folder to configuration folder, Beta-iphoneos, in my case.
After coping the content from Release-iphoneos to your $configuration$-iphoneos folder Xcode should correctly compile, build and run your project.
I just ran into a similar problem and discovered that my schemes referenced old configurations, configurations that no longer existed. Once I updated them to the correct configurations the build succeeded.
(I'm leaving this comment more than a year after the original post. It's possible that what I ran into is completely different from what was originally reported. Still, it took me quite a while to track the problem down, so I wanted to leave a note that might save others time.)
Clearing the derived data solved the issue in my case. I have Microsoft Azure Devops CI Pipeline, to clear the derived data I have to edit the Xcode build task and in the "Actions" field add this command: clean.
What worked for me: I removed my import WebMIDIKit line and added it again.
Based on #sliwinski.lukas's answer, in my case the ${CONFIGURATION} was outputting "Release", so it was just copying the Release folder itself which was no good. I simply hardcoded my configuration name, and flipped Release and MyConfiguration, and it worked. I put the following code right before "Compile Sources" in the "Build Phases" tab:
cp -f -R "${SYMROOT}/MyConfiguration${EFFECTIVE_PLATFORM_NAME}/" "${SYMROOT}/Release${EFFECTIVE_PLATFORM_NAME}/" || true
Also importantly, I had to add this in the project that used the SPM and not in the main app.
I just ran into a similar problem when running xcodebuild from the command line. I was passing CONFIGURATION_BUILD_DIR=build but found that it needs to be an absolute path: CONFIGURATION_BUILD_DIR=$(pwd)/build solved the problem.
Might I shed a bit more light on your plight...
I'm working on a fairly large iOS app (6680 files) whose result is composed of many frameworks and a mixed bag of podfiles, swift packages, legacy ObjC code (that still outnumbers newer Swift stuff).
Whenever we deal with swift packages, we need to wrap them in frameworks because it simplifies podfile & dependency resolutions when we have our remote (Jenkins) build system eat everything up to spew binaries for internal QA & ultimately, Enterprise & AppStore publishing.
Earlier today, I was dealing with one such swift package wrapped in a framework and all the issues listed above hit me square in the face.
After stashing, pushing usable code and then reapplying my stashed framework wrapper to the swift package, I used a different route than opening our project's workspace where a bunch of projects and targets are collected.
Opening the lone framework wrapper seems to have kicked XCode (13.3.1) into submission and at that point, the target settings "Frameworks, Libraries and Embeddable" section was actually able to display the swift package's "Foo" binary. Added it, and then everything was playing nice.
So, if you're still having problems, try simplifying the problem by opening smaller morsles if you can. Or start making these wrapper frameworks (if it's at all possible) so that you can actually manage smaller bites before integrating them on XC's platter.
For me, I go to Xcode -> File (The one on mac top bar) -> Packages -> Update to Latest Package Versions. This solved my problem.
In order to keep incremental builds working I had to specify the output files of "Fix SPM" build phase like so:
I'm using a library that has supports another library with a wide range of versions as a peer dependency. Unfortunately, one of the child projects of the workspace pulls in a version different from the child project that uses the library. As a result, they end up requiring different versions.
I'm trying to use selective resolutions to handle this and force it to use the correct version (https://yarnpkg.com/lang/en/docs/selective-version-resolutions/) but I'm not having any luck.
It's possible I'm misunderstanding how to utilize these.
My current setup is I have a root workspace with these children inside:
Project A package.json (which is the source of the issue):
dependencies: {
backbone.marionette: '2.4.1'
}
Project B package.json (which is the application having issues):
dependencies: {
backbone.marionette: '1.8.8',
#organization/UILibrary: '0.0.22'
}
The #organization/UILibrary (which is outside the workspace) package.json looks like so:
peerDependencies: {
backbone.marionette: ">= 1 < 3"
}
Unfortunately, even though Project B has no dependency on Project A, when #organization/UILibrary is pulled into Project B it gets backbone.marionette version 2.4.1 for it's requires (whereas the requires local to Project B get 1.8.8).
My attempt to use resolutions is updating Project B package.json to this:
dependencies: {
backbone.marionette: '1.8.8',
#organization/UILibrary: '0.0.22'
},
{
"resolutions": {
"#organization/**/backbone.marionette": "1.8.8",
"#organization/backbone.marionette": "1.8.8",
"#organization/UILibrary/backbone.marionette: "1.8.8",
"#organization/UILibrary/**/backbone.marionette: '1.8.8"
}
Any ideas? Based on some digging in yarn's issues and some of their selective dependency PRs (see https://github.com/yarnpkg/yarn/issues/4874) I believe it may be due to the fact that the UILibrary is scoped (has a slash).
I ran into something similar recently; what I found is that resolutions only works in the root package.json. Try moving the resolutions there instead of in Package B's.