Summary
While I understand why it could be dangerous to auto import transitive public dependencies, is there a way to enable auto-import when depending a local package via path?
Setup
The Flutter/Dart project consists of three packages
app
repository
api_client (auto-generated open api & models)
I do need api_client models in app & repository, but only want to import it in the repository package.
app/pubspec.yaml
dependencies:
# want to remove api_client here without loosing auto-import ability
api_client:
path: ../api_client
repository:
path: ../repository
repository/pubspec.yaml
dependencies:
api_client:
path: ../api_client
Related
I have project structure
-core_data
-core_domain
-core_ui
-core_launcher
The dependency of these 4 projects is
core_launcher -> core_ui -> core_domain -> core_data
4 projects are located in the same directory and I include one to another via pubspec.yaml file (for example core_launcher/pubspec.yaml):
dependencies:
flutter:
sdk: flutter
core_ui:
path: ../core_ui
The same thing I do with all projects to make dependency hierarchy.
The problem is that I can import all files from core_ui subproject when I'm currently editing some file in core_launcher but VSCode doesn't see any classes from his parents
(core_domain & core_data).
However, I can input import 'blah-blah-blah manually and VSCode see this class and import works well, but I can't do that with hit Alt+Enter that I do for fast-import.
So, I'm wondering why autocomplete is not working for inherited libraries.
Somebody had the same issue?
Code completion will only show classes from your direct dependencies. There are two possible reasons for this:
Relying on transitive dependencies is not a good idea, because it's possible that your dependencies will remove or change their dependencies and not consider that a breaking change.
If code completion listed all classes from all transitive dependencies the code completion list would be huge and include classes from packages you do not recognise (because they are just other packages dependencies). This would be a bad user experience and make it easy to accidentally rely on packages that are not listed in your pubspec.yaml.
The fix is to explicitly list core_domain and core_data in your pubspec.yaml too, because if your project is using classes from them, then they are dependencies.
How do i create a directory of shared code between Integration tests and Widget tests in flutter? There could be quite a bit of it since they use the same API now as of the new official
in Android native you can do the below in order to have code that is shared between local non-instrumented UI tests (Roboelectric under the hood) and instrumented Espresso tests with the Espresso API. And of course miscellaneous shared helpers, mocks, whatever.
How do i achieve a similar goal in Flutter?
// This allows us to share classes between androidTest & test directories.
android.sourceSets {
test {
java.srcDirs += "$projectDir/src/testShared"
}
androidTest {
java.srcDirs += "$projectDir/src/testShared"
}
}
This could be achieved using a shared package (namely test_base).
Create a package for your test codes (confusion avoidance: your code will be written in its lib folder).
run:
flutter create --template=package test_base
Add your main package as a dependency to test_base so you have access to your main package codes.
test_base/pubspec.yaml:
dependencies:
<your-package-name>:
path: ../
Add test_base to your main library as a dev-dependency.
./pubspec.yaml:
dev_dependencies:
test_base:
path: test_base/
Now you can import the test_base package in your widget/integration tests.
Note: This way within test_base you can import packages of transitive dependencies (dependencies of your main package) without a compilation error. But it is discouraged in dart to explicitly import packages of dependencies you don't explicitly define in test_base/pubspec.yaml and it's probable to face linter or compilation warnings in future versions of dart (currently it's 2.13.4 and no warnings). Which means then you need to explicitly define those dependencies in test_base/pubspec.yaml. Though I think this is the case it would be harmless to import transitive dependencies packages.
So I have received a project which requires e-commerce, food ordering and car hailing services like Grab to be inside one app. I have delivered all these 3 apps in different projects before and for this new project I'm wondering whether it is possible to combine all my previous source code into one project, running on different dependencies.
You can create packages for all 3 modules (food, e-commerce, car-hailing services)
To create a Flutter package, use the --template=package flag with flutter create:
flutter create --template=package food
Folder Structure
lib
packages
- food
- e_commerce
- car_hailing_service
Import this in the main module's pubspec.yaml file
dependencies:
flutter:
sdk: flutter
# My Custom Packages
food:
path: packages/food
e_commerce:
path: packages/e_commerce
car_hailing_service:
path: packages/car_hailing_service
If you have any common functionalities for all 3 packages then create a separate package for that also and import that common package for all 3 packages.
Refer to this document for creating flutter packages. I hope this helps you.
I'm trying to use Swift Package Manager's binaryTarget to include the Stripe xcframework available here https://github.com/stripe/stripe-ios/releases/tag/v19.3.0. The package manager doesn't complain, and lets me link to it, but I can't import it im. I've made a sample repo to show it here https://github.com/martyu/StripePackageTest. Am I missing something?
First of all, your example is not testable because you have forgotten to provide a version tag, so this is not a real package.
Second, and more important, I think you have a misconception about how a package works as a binary target. You seem to think that your Swift Package can contain code that sees the XCFramework. (That's why you are trying to import in the framework module in the Sources code of the package.) That's wrong. It's the app that imports the framework module. The package is merely a way of distributing the framework.
In other words, you can write a source code package or a framework-bearing package. One package cannot be both.
But of course you can write a source code package that depends on a framework-bearing package.
First, you don't need a version tag for it to be "real package". You can specify package dependencies via commit SHA and branch as well. Also you can add local package repos in xcode via file://. Note, this is NOT the same as a local dev override.
I didn't have much luck with swift build but I did get it to work fine by creating an app in Xcode and adding the package to it. I think this is what #matt is getting at. You need to import it into a project (xcode, or another SP) and then xcode will assemble all the dependencies when it ~~builds~~ feels like it.
Here's the modified Package.swift I used. I changed the name to Example (as that's presumably the SDK you are building which depends on Stripe). You can include "Stripe" in the Example library's targets if you want it embedded in its framework. Otherwise the client app just needs to import it as well (via the tickboxes when you add it in Xcode, or via dependencies in another Package.swift).
// 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: "Example",
platforms: [
.iOS(.v11)
],
products: [
.library(
name: "Example",
type: .dynamic,
targets: ["Example"]),
.library(
name: "Stripe",
targets: ["Stripe"])
],
dependencies: [],
targets: [
// I thought this was defining the Stripe binaryTarget...
.binaryTarget(name: "Stripe",
url: "https://github.com/stripe/stripe-ios/releases/download/v19.3.0/Stripe.xcframework.zip",
checksum: "fe459dd443beee5140018388fd6933e09b8787d5b473ec9c2234d75ff0d968bd"),
// ... and then linking it to the Example project here via "dependencies" ...
.target(name: "Example", dependencies: ["Stripe"], path: "Sources")
// ... so when I'm in "Example" files, I thought I'd be able to import "Stripe" to them
]
)
I am trying to install the MongoDB swift driver using the swift package driver. I followed their instructions and installed the mongo-c-driver using home-brew. I then created a new directory and within a new project using:
swift package init --type executable
I then added the dependencies to the Package.swift file.
When trying to run any command that summonsswift package resole in the directory, i get the following error:
error: the package PackageReference(identity: "mongo-swift-driver", name: nil, path: "https://github.com/mongodb/mongo-swift-driver.git", isLocal: false) # 0.0.2 contains revisioned dependencies:
PackageReference(identity: "swift-bson", name: nil, path: "https://github.com/mongodb/swift-bson", isLocal: false) # master
PackageReference(identity: "swift-mongoc", name: nil, path: "https://github.com/mongodb/swift-mongoc", isLocal: false) # master
I made sure that everything is up to date and that the first line of the Package.swift is // swift-tools-version:4.0
I would like to know what these revisioned dependencies are, as i have not found anything useful. And how this error can be resolved.
The Swift Evolution proposal that introduced the ability to specify branches instead of revisions in SPM packages (SE-0150 says this:
While this feature [specifying branches] is useful during development, a package's dependencies should be updated to point at versions instead of branches before that package is tagged for release. This is because a released package should provide a stable specification of its dependencies, and not break when a branch changes over time. To enforce this, it is an error if a package referenced by a version-based dependency specifies a branch in any of its dependencies.
It looks like the version 0.0.2 of the parent package that you're using did not follow the rule to switch to specific versions for its dependencies and SPM doesn't allow this.
If possible, you should try to use a newer version of the parent package that fixes this issue. If a newer version doesn't exist, you may have to override the dependency and fix it yourself (I believe you can use swift package edit to do that — or fork the dependency and point to your own repo, of course.)