If I need any dependency I use them under dependencies like this
dependencies:
flutter:
sdk: flutter
provider: ^3.2.0
http: ^0.12.0+3
get_it: ^3.1.0
connectivity: ^0.4.6
email_validator: ^1.0.4
shared_preferences: ^0.5.4+8
google_maps_flutter: ^0.5.21+14
When I can use packages uder dev_dependencies? I don't know what I have to see in the packages so that I can decide which dependency goes to which category.
dev_dependencies:
Pub supports two flavors of dependencies: regular dependencies and dev_dependencies. Dev dependencies differ from regular dependencies in that dev_dependencies of packages you depend on are ignored.
For Example:
If you are developing a package, and you want some packages which are only imported for testing purpose and not the actual implementation, then such packages should go under dev_dependencies. When you are importing a package, pub gets every package that your imported package depends on. Since pub ignores dev_dependencies, the packages which were used for testing won't be fetched by pub.
Related
I want to have a rpm package build with Copr1. My current build target list is Fedora 35, 36, rawhide and Centos 7 and Stream 8. I have not yet created the copr project.
Compiling on one of my machines, the package builds successfully on the Fedora variants with mock. The problem is that on Centos variants one of the build dependencies and some of its dependencies are not available. I have found appropriate srpm files and compiled them on one of my machines with the Centos Stream 8 (one of them required two custom patches). With those custom dependencies I am able to successfully compile the original package.
So just to be clear, the problem is that the spec file contains for example
BuildRequires: libsomething
where libsomething is available as a plain upstream package in some of the build targets while needs an additional custom repo for some other build targets.
The FAQ says the following about dependencies:
Can I depend on other packages, which are not in Fedora/EPEL?
Yes, they just need to be available in some yum repository. It can either be another Copr repo or a third-party yum repo (e.g jpackage). Click on “Edit” in your project and add the appropriate repositories into the “Repos” field. Packages from your project are available to be used at build time as well, but only for the project you are currently building and not from your other projects.
But this sounds like an all or nothing approach, and I absolutely do not want to override the already existing upstream packages, only provide them when they are missing.
So what strategy do people use to handle this?
Update: I have now created copr projects and made some attempts at building (after resolving dependencies of dependencies in several levels), but the problem is as I describe above. If I add copr://hlovdal/projectname as a build dependency then epel-8-x86_64 compiles fine because it is provided with the missing dependencies while fedora-35-x86_64 fails because the repository does not have any fedora packages. If I remove the repo epel fails while fedora succeeds.
I also attempted to add the base url from the corresponding /etc/yum.d.repo file, and only hardcode epel instead of $distname hoping that the fedora builds would just ignore non-existing/wrong repo setting, but the build does not like that and still fails.
1 Copr is Fedora's freely available build system.
The Webpack/Vue ecosystem is a very fragile one, with minor updates to loaders regularly breaking the build. It's basically a dedicated job to curate a working Webpack config together with a list of the exact dependency versions that are needed to make it work.
This Webpack config can easily be kept in a repository and then copied to many different projects and imported in their local webpack.config.js because webpack.config.js is just Javascript.
I'd like to do the same thing with package.json, i.e. have the curated list of dependencies in a separate file and when running npm install have them added to any other dependencies a project might have.
Do npm or yarn or any other external tools offer such a functionality?
Are you specifically trying to use a js file? If so, I don't have an answer, but if json is enough, you can just make an node package that just has the dependencies you want in it. Someone that includes your package will then pull in all the dependencies listed in your package because npm pulls in the dependencies of a project's dependencies.
Also see https://stackoverflow.com/a/55483109/14144258
I'm trying to understand the Swift Package Manager manifest - Package.swift when wrapping an existing work, with regards to a version. As an example, XMLDictioonary, is my fork where I wanted to expose it to SPM; so far I have:
// swift-tools-version:5.1
// The swift-tools-version declares the minimum version of Swift required to build this package.
import PackageDescription
let package = Package(
name: "XMLDictionary",
platforms: [
.macOS(.v10_13), .iOS(.v11), .tvOS(.v11),
],
products: [
// Products define the executables and libraries produced by a package, and make them visible to other packages.
.library(name: "XMLDictionary", targets: ["XMLDictionary"]),
],
dependencies: [
// Dependencies declare other packages that this package depends on.
],
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 which this package depends on.
.target(name: "XMLDictionary", dependencies: [],
path: "XMLDictionary",
publicHeadersPath: "."),
]
)
which Xcode (12) supports so long as my version rule specifies master, but I'd like it to be 1.4.1 as is the upstream. I might at some point in the future diverge.
But adding what I think it should be
dependencies: [
// Dependencies declare other packages that this package depends on.
.package(
url: "https://github.com/slashlos/XMLDictionary.git",
from: "1.4.1"
)
fails fails in Xcode SPM addition
and before that, locally the build fails:
error: cyclic dependency declaration found: XMLDictionary -> XMLDictionary
which I believe is telling me the dependency rule is on itself?
So how does one specify the version dependency ?
The Package.swift is the manifest of your framework and it has to be placed in the root directory. You did everything correctly.
If you want to import your framework in your app you should specify the Github repo url where to import the framework and eventually the version number. That version number is taken by the tags you have in your Github repo. If you set 1.4.1, SPM will checkout the code on your repository at the time it was tagged as 1.4.1 (the tag correspond to a specific commit!). BUT at that time the Package.swift wasn't there because you added it some commits later.
If you want use the semantic version to import your framework you should create a tag on your last commit. So when SPM will download that tag it's able to find your Package.swift file in there.
We have a monorepo using lerna and yarn workspaces. Multiple teams contribute packages to it and there are some common dependencies where we want to force people to use the same version.
What are the options to force all packages to use the same version of specific dependencies? Is there a way to achieve that without writing custom scripts?
I want to prevent this situation:
my-repo/
packages/
pkg-A/
package.json
"address-validator": 1.1.0
pkg-B/
package.json
"address-validator": 1.2.0
I know you can use lerna add or lerna run to add / upgrade in unison, but how to prevent an individual from unknowingly making their package unique?
I just noticed one nice solution to this problem in facebook's create-react-app. They import (all?) external dependencies in the react-dev-utils package and export them from there. Then all the other packages, like react-scripts, import dependencies from react-dev-utils.
This is nice because you only need to worry about using the latest version of one package (e.g. react-dev-utils) in order to use the latest version of all of the things you want to control. Also, it's flexible because you can override one of the dependencies by importing a different version directly.
So it could look like:
my-repo/
packages/
my-deps/
pkg1.js // <--- module.exports = require("pkg1");
package.json
"pkg1": 1.2.0
foo/
index.js // <--- const pkg1 = require("my-deps/pkg1")
package.json
"my-deps": 1.1.0
My project depends on angular2 beta.6 and another project that depends on angular2 beta.0.
package.json for my project
"dependencies": {
"angular2": "2.0.0-beta.6",
"another-project": "0.0.1"
}
package.json for another-project
"dependencies": {
"angular2": "2.0.0-beta.0",
}
When I npm install my project, it installs angular2 twice:
node_modules/angular2 (beta.6)
node_modules/another-project/angular2 (beta.0)
Trying to understand how npm3 decides to nest angular2 beta.0. Is it because both are called angular2 and hence they can not both sit at the top level?
Trying to understand how npm3 decides to nest angular2 beta.0. Is it because both are called angular2 and hence they can not both sit at the top level?
Yes, this is correct. Node code require's a module by name, using code like this:
require('angular2');
Node itself is not aware of the different versions, that's the job of npm, so it just uses whatever module matches in the require path first, relying on matching directory names.
npm accommodates this by installing specific versions in directories for each module when a conflict occurs, so that the require path will include that first.
Yes, it is because of the beta.0. Because npm has found another version of angular2 on the global level, it will install it locally.
npm3 will install globally dependencies only if there is no other versions of the dependencies on a higher level.
Here is a little example I've found :
[node_modules]
dep A v1.0
dep B v1.0
dep A v1.0 (uses root version)
dep C v1.0
dep A v2.0 (this version is different from the root version, so it will be an nested installation)
Flat dependencies were introduced in npm v3. The documentation can be found here https://docs.npmjs.com/how-npm-works/npm3.
To answer your question from the docs
However, since B v1.0 is already a top-level dep, we cannot install B v2.0 as a top level dependency. npm v3 handles this by defaulting to npm v2 behavior and nesting the new, different, module B version dependency under the module that requires it -- in this case, module C.
So order matters. The module you install first will get it's dependency on the top level. Subsequent modules will have nested dependencies.
you can run npm dedupe to remove nested module dependencies if they exist in the top level.