Dart any dependency usage in pubspec.yaml for multi module project - flutter

I need something similar in Dart to what Maven has with a parent-pom dependencyManagement structure.
I have 2 modules in Dart, api and core.
api/pubspec.yaml:
...
dependencies:
http: '>=0.12.0 <0.13.0'
meta: '>=1.0.0 <2.0.0'
...
core/pubspec.yaml:
...
dependencies:
api:
path: ../api
# Meta is added again with a version number
meta: '>=1.0.0 <2.0.0'
redux: '4.0.0'
...
So if I change the dependencies in core/pubspec.yaml to 'any' if they already exist in api/pubspec.yaml:
...
dependencies:
api:
path: ../api
# No version number is needed, the exact version will come from the dependency
meta: 'any'
redux: '4.0.0'
...
This seems to be working, but the official site does not mention this feature, instead:
The string any allows any version. This is equivalent to an empty version constraint, but is more explicit. Although any is allowed, we don’t recommend it.
Is this an unintended good use case of the 'any' or this is a bad idea? (I am confident api dependency will always exist and declare meta, they are all my modules.)

Related

how to use different pubspec.yaml in different environmnet with flutter

is it possible to use different pubspec.yaml in different environmnet? for example, in develop environment I use the dependencies from local folder, and config the local folder in the pubspec.yaml like this:
dependencies:
info:
path: ../common/info
in production environment I use the dependencies like this:
dependencies:
info: 1.0.0
is it possible to do like that? I do not want to change the pubspec.yaml every time. I have read the solution from here https://github.com/flutter/flutter/issues/45769 but I am not sure it is the proper way.

How to suppress depend_on_referenced_packages just for a specific import, not the whole file?

After upgrading to Flutter 3.0 I started to get a lot of depend_on_referenced_packages lint issues when running flutter analyze. If I remove the reported imports the compilation breaks. Most of the issues are with package:collection/collection.dart which provides extension methods.
Currently the best I could find is to suppress this lint for the affected files by adding // ignore_for_file: depend_on_referenced_packages. However I like this lint (and in general I'd want to keep as much lints enabled as possible), so is there a way to suppress the lint only for a just a specific import and not for all imports in the file?
Relevant sections of pubspec.yaml:
...
environment:
sdk: ">=2.17.1 <3.0.0"
flutter: ">=3.0.1"
...
dev_dependencies:
flutter_lints: ^2.0.1
Running:
$ flutter analyze
...
info • Depend on referenced packages • lib/preferences/palette_spec.dart:3:8 • depend_on_referenced_packages
info • Depend on referenced packages • lib/ui/parts/circular_menu.dart:5:8 • depend_on_referenced_packages
...
Source code examples:
database_utils.dart (firstWhereOrNull is from collection.dart):
...
import 'package:collection/collection.dart';
...
Activity? _getActivityById(int id) {
return activities.firstWhereOrNull((element) => element.id == id);
}
...
Record? _getRecordById(int id) {
return records.firstWhereOrNull((element) => element.id == id);
}
palette_spec.dart (forEachIndexed is from collection.dart):
...
import 'package:collection/collection.dart';
...
paletteStr.split(",").forEachIndexed((index, colorStr) {
...
});
circular_menu.dart:
...
import 'package:vector_math/vector_math.dart' as vector;
...
final angle = vector.radians(90.0 / (widget.children.length - 1) * index + angleFix);
Note: the root cause is that collection is brought in as a transitive dependency.
Originally I misunderstood the lint. Explanation to Petr's solution: when he says "lint is reported if you depend on a transitive dependency" it means that somewhere in my code I have an import which imports stuff from that dependency. But at the time of the lint that dependency is only transitive, not direct. Therefore if I'd decide - for whatever reason - to not depend on the package which brings that in then suddenly I'd have an error out o the blue for that import. The lint tries to make that dependency graph more direct.
This lint is reported if you depend on a transitive dependency. Do you have in your pubspec.yaml defined collection?
dependencies:
collection: ^1.16.0
I had same issue but after defining dependency, lint issue is gone.

No such module in a Swift Package using Xcode - package listed in dependencies

I create a blank template package:
> swift package init --name Temp
> open Package.swift
Xcode Version 13.2.1 (13C100) opens the package.
I add a dependency to the package.
dependencies: [
.package(url: "https://github.com/johnsundell/publish.git", from: "0.7.0")
],
Xcode > Product > Build succeeds at this point.
I edit Temp/Sources/Temp/Temp.swift to insert the first line the package that is defined in dependencies.
import Publish
A build now generates the following error:…/Temp/Sources/Temp/Temp.swift:1:8: error: no such module 'Publish'.
I feel certain this is an Apple bug. Or I could be missing something.
There are several posts about this problem when there is an xcodeproj and the additional structure that provides. Some of them hint at workarounds that help some people.
Has anyone seen this and/or know of how to resolve it?
Apple's Creating a Standalone Swift Package with Xcode document doesn't provide any insight.
thanks for the chatter in the comments, #Larme & #koen, it helped
The issue was user error (and/or a documentation lapse). Living on the (bleeding) edge.
Sometimes updates from changes are slow or require a clean or a relaunch.
Xcode auto-generates Schemes from the targets defined in your package. My build was targeting MyTarget.
Two things were missing:
name: "Publish" was not included in the package dependency - it's needed so you can reference it below (or maybe this can be derived, it's hard to tell because of Xcode refresh issues), and
a reference is needed in the dependencies for each target using the package-dependency, i needed to add dependencies: ["Publish"] in the related target
dependencies: [
.package(name: "Publish", url: "https://github.com/johnsundell/publish.git", from: "0.7.0")
],
…
targets: [
.target(
name: "MyTarget",
dependencies: ["Publish"]),
]

How do I make a shared directory to share code in flutter between integration tests and widget tests?

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.

SPM - Package contains revisioned dependencies

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.)