I want to install latest Flutter packages in my android studio project.
In npm, npm install <package name> installs latest packages automatically and npm update updates all packages automatically.
Is there any way to do this in Flutter?
Yes it is possible to update existing packages. Use the flutter command below:
flutter pub outdated
This was introduced in Dart 2.8:
As of Dart 2.8, you can use pub outdated, a new tool for automatically determining which of your dependencies need to be updated to the latest and greatest versions.
With a release of Flutter 2.0 you can now upgrade flutter dependency packages automatically using these below command lines:
flutter pub outdated
flutter pub upgrade --major-versions
Let's say you have these packages in your pubspec.yaml file
dependencies:
foo: ^1.0.0
bar: ^5.0.0
And at some point in future there is an update available for both of them, and you decide to run
flutter pub outdated
It would now list something like:
Dependencies Current Upgradable Resolvable Latest
foo 1.0.0 1.2.0 1.2.0 1.2.0
bar 5.0.0 5.3.0 6.0.0 6.0.0
You see there is no breaking change for foo, since it is still on 1.x.x, however, bar has got a breaking change, it has been updated from 5.x.x to 6.x.x. So what should you do now?
If you safely want to update the packages without breaking your code, run
flutter pub upgrade
This would now create pubspec.lock file with
packages:
foo:
version: "1.2.0"
bar:
version: "5.3.0"
If you want to update both of them to the latest version, you'll have to manually do it in pubspec.yaml file by specifying (foo won't need manual version):
dependencies:
bar: ^6.0.0
This would create pubspec.lock file with
packages:
foo:
version: "1.2.0"
bar:
version: "6.0.0"
You can check version is out dated or not using flutter pub outdated command.
in output you will get all outdated versions.
Output:
Dependencies Current Upgradable Resolvable Latest
carousel_pro *0.0.13 *0.0.13 1.0.0 1.0.0
firebase_auth *0.15.4 *0.15.5+3 0.16.0 0.16.0
Here, current version show, which you are using and latest show which package version is available.
Note: You have to specify latest version in pubspec.yaml file and then you have to run.
flutter pub get
Related
I have two versions of a package e.g.
#mycompany/mylob v2.0.0
and
#mycompany/mylib v3.0.0
version 3.0.0 has breaking changes from version 2.0.0 but we do not have the capacity to upgrade everything to 3.0.0 as of yet.
Another developer has upgraded an internal package e.g. #mycompany/utils to use version 3.0.0 and that is installed into our codebase so now we are getting compatibility errors when running the build as #mycompany/utils requires version 3.0.0 but the rest of the code in that repository wants version 2.0.0.
Is there a way with yarn/npm that I can install #mycompany/mylib v3.0.0 for #mycompany/utils and have the rest of the code refer to v2.0.0?
You can use custom alias installs:
npm i custom-name:#mycompany/mylib#3.0
You can change custom-name to any valid package name you want to use.
After that you can import the package with this alias name. e.g.:
require("custom-name")/ import * from "custom-name"
For npm install specific version, use npm install [package-name]#[version-number].
In the package.json of my reactjs webpack project I specified the version number of a dependency that I wanted to download through a npm install as ^0.0.130 where the latest version of that dependency is 0.0.145.
But when I hit the npm install its downloading 0.0.130, not the latest version.
But when I specified the version number as ^0.0.145 its downloading the latest version of 0.0.145.
I cannot figure out why its not downloading the latest version though i used caret sign (^) with the eailer number.
Can anyone help me to figure out why this is not happening in the right way.
^0.0.145 matches the most recent ^0.x.x version
To upgrade to latest version for the 1.0.0 major release you will need to use something like^1.0.0
Yes, That can be happen.
After a component is publishing using npm publish command the latest version is usually the highest version number. But if a component is published using npm publish --tag latest that version is marked as the latest one. So though you published new versions after that the latest version will be the eariler version.
In above scenario they published 0.0.130 as the latest version using npm publish --tag latest. So though they published new versions after that, ^0.0.130 is the latest one.
0.0.145
.......
.......
.......
0.0.131
0.0.130 --------latest
0.0.129
0.0.128
0.0.127
when I install a new package in node js project with npm, without specifying a exact version, what is the package version going to install by default?
It would be the "latest" as indicated by the package information.
Source : https://docs.npmjs.com/cli/install
That is usually set as the latest stable release version, usually not the beta version and other unstable releases. But again, it all depends on each package, this is just some configuration information to be set by the maintainer(s) of the package.
One of our apps (my-app) dependencies is an npm lib we publish to npm (my-lib).
name: my-app;
version: <my-app-version>
dependencies: {
my-lib: <my-lib-version>
}
As a company we are committed to support the current version and 1 older version.
my-app 1.0.0 depends on my-lib 1.0.0
name: my-app;
version: 1.0.0
dependencies: {
my-lib: 1.0.0
}
my-app 2.0.0 depends on latest my-lib which is 3.1.0
name: my-app;
version: 2.0.0
dependencies: {
my-lib: 3.1.0
}
We have a bug in my-lib which we must fix for both.
The easy thing to do would be fixing in 3.1.0,
but my-app 1.0.0 can't adopt 3.1.0 as it introduces breaking changes, and must stay in version 1.X.X.
What's the standard way to fix my-lib in both?
If you decide to update both 1.x.x and 3.x.x versions, you might keep working on 2 separated GIT branches and publish 2 separate patch releases on NPM.
I use npm to install some command line tools. Having the itch to always be up to date, I found the command npm -g outdated.
What is the difference between the columns wanted and latest?
The documentation states:
The resulting field 'wanted' shows the latest version according to the
version specified in the package.json, the field 'latest' the very
latest version of the package.
However I don't find it clear at all.
For example on my system I get:
Package Current Wanted Latest Location
cordova 5.3.1 5.3.3 5.3.1 lib
npm 3.3.4 3.3.4 3.3.3 lib
How can wanted be higher than latest? It seems to contradict:
the field 'latest' the very latest version of the package
Which version should I update to (I only use the command-line, not any node.js code)?
The wanted field makes no sense in the context of a --global run as there is no package.json to define which version you require.
Which version should I update to (I only use the command-line, not any node.js code)?
The latest version seems as a good choice if you like to live on the edge.
The wanted column seems like a bug, it is reported in github many times.
Update (after checking source)
The documentations seems a bit misleading so lets clarify:
The resulting field 'wanted' shows the latest version according to the version specified in the package.json...
As there is no global package.json, the version constrain used is '*' (set here).
Then the wanted version is the latest version of the package according to semver.
the field 'latest' the very latest version of the package.
Thats not true, what you get is the dist-tag "latest", that usually matches the latest version (see here). There are some packages that uses those tags to manage what get shown (like npm).
Which version should I update to (I only use the command-line, not any node.js code)?
It seems that the edge is wanted.
Update:
On my machine currently npm -g outdated shows:
Package Current Wanted Latest Location
babel-cli 6.1.18 6.2.0 6.2.0
generator-rise 1.7.0 2.1.0 2.1.0
npm 3.3.6 3.5.0 3.4.1
The version 3.5.0 exists as a release on github but has not yet been published to npm. So it is somehow getting picked up from there but glossing over the npm source I couldn't find any evidence to support this argument.
From the official documentation:
The resulting field 'wanted' shows the latest version according to the
version specified in the package.json, the field 'latest' the very
latest version of the package.
To elaborate:
npm allows you to specify a range of versions in your package.json, examples are available here. The maximum version that can be accommodated in the specified range is the wanted column.
This may be different from the version installed (if at all) because package.json may have changed in the meanwhile, or the author may have pushed a new minor release in between.
Considering your example, cordova#5.3.3 is marked as “wanted”, but “latest” is cordova#5.3.1 because npm uses dist-tags to manage its latest and next release channels.
npm update will install the newest version, but npm install cordova (with no semver range) will install whatever’s tagged as latest.
link to documentation