kbknapp / cargo-outdated Goto Github PK
View Code? Open in Web Editor NEWA cargo subcommand for displaying when Rust dependencies are out of date
License: MIT License
A cargo subcommand for displaying when Rust dependencies are out of date
License: MIT License
Or perhaps make it the default?
Thanks to #58, this is possible if the crate has a virtual manifest. However, it would be useful to trigger this behavior from crates without a virtual manifest as well.
There's a lot of unwraps...now that it works most of them should be removed.
Cargo outdated errors on Windows with this output:
Parsing Cargo.lock...Done
Setting up temp space...Done
Checking for SemVer compatible updates...Done
Parsing the results...Done
Cleaning up temp semver files...Done
error: permission denied
Creating temp space for latest versions...error: third party subcommand `cargo-outdated.exe` exited unsuccessfully
To learn more, run the command again with --verbose.
Hey there,
I was thinking about using this in CI. Would it be possible to add an argument so that cargo outdated
exits with 1
?
Thank you so much
It take too long to compile cargo. An alternative is to use cargo_metadata, which offers an api over the cargo metadata
command.
Print out the dependency tree to a JSON
Say the following dependency tree is generated:
hello_world -> hyper (0.10.12) -> [url, unicase, ...]
...and cargo outdated -r hyper -d 0
is executed against the package
Actual output:
All dependencies are up to date, yay!
Expected output:
Name Project Ver SemVer Compat Latest Ver
hyper 0.10.12 -- 0.11.2
cargo outdated
command failed in case of connection through proxy server:
error: failed to load source for a dependency on
byteorder
Caused by:
Unable to update registry https://github.com/rust-lang/crates.io-index
Caused by:
failed to fetchhttps://github.com/rust-lang/crates.io-index
Caused by:
[12/-16] proxy authentication required, but no callback provided
error: failed to parse manifest at
%TEMP%\...
Caused by:
can't find librarysciter
, rename file tosrc/lib.rs
or specify lib.path
As I see, this error is coming from cargo/targets.rs. So I am not sure whether this error is in cargo-outdated or in cargo itself.
And yes, path = "src/lib.rs"
resolves it. Partially, because it does not show updates, just prints
All dependencies are up to date, yay!
despite lazy_statis
is 0.2 in toml and 1.0 at crates.io. And if I create a new --bin project and test it, cargo outdated
shows its update (lazy_static 0.2.11 --- 1.0.0
). Strange.
Project: https://github.com/sciter-sdk/rust-sciter.
env:
rustc 1.22.1
cargo 0.23.0
cargo-outdated v0.7.0
Name Project Ver SemVer Compat Latest Ver
aho-corasick->memchr 0.1.11 RM RM
Might be nice to have this explained somewhere.
I havenβt actually tested it myself, but from the README:
Name Project Ver SemVer Compat Latest Ver
clap 1.2.3 1.2.5 1.4.7
1.4.7 is compatible with 1.2.3 according to SemVer. Only before 1.0.0 are all bets off for minor version number increments.
cargo outdated
shows that all dependencies are up to date when they are clearly not.
Here's an example:
$ cat Cargo.toml
[package]
name = "outdated_test"
version = "0.1.0"
authors = ["Dabo Ross <[email protected]>"]
[dependencies]
pistoncore-window = "0.8"
$ cargo build
Updating registry `https://github.com/rust-lang/crates.io-index`
Downloading pistoncore-window v0.8.0
Downloading pistoncore-input v0.4.0
Compiling rustc-serialize v0.3.16
Compiling bitflags v0.3.2
Compiling piston-float v0.1.0
Compiling shader_version v0.2.1
Compiling piston-viewport v0.1.0
Compiling pistoncore-input v0.4.0
Compiling pistoncore-window v0.8.0
Compiling outdated_test v0.1.0 (file:///home/daboross/outdated_test)
$ cargo outdated
Checking for SemVer compatible updates...Done
Checking for the latest updates...Done
All dependencies are up to date, yay!
$ cargo search "pistoncore-window"
Updating registry `https://github.com/rust-lang/crates.io-index`
pistoncore-window (0.9.1) A library for window abstraction
As you can see, a new version of pistoncore-window
(0.9.1) is clearly available, but cargo outdated
doesn't show this.
Cargo.toml
[package]
authors = ["Jake Goulding <[email protected]>"]
name = "top-crates"
version = "0.1.0"
[dependencies]
cargo = "0.19.0"
hyper = "0.10.9"
hyper-native-tls = "0.2.2"
lazy_static = "0.2.8"
serde = "1.0.1"
serde_derive = "1.0.1"
serde_json = "1.0.0"
toml = "0.4.0"
A snippet of the output looks like this:
cargo 0.19.0 --- 0.20.0 Normal ---
cargo->chrono 0.2.25 --- Removed Normal ---
cargo->toml 0.3.2 --- 0.4.5 Normal ---
chrono->num 0.1.40 --- Removed Normal ---
cmake->gcc 0.3.51 0.3.53 0.3.53 Normal ---
As I read through this output, I'm surprised by the appearance of chrono
and cmake
on the left hand side β those aren't dependencies of mine. After thinking about it for a while, I realize that they are transitive dependencies.
Preparing this report, I see that there's a --depth
parameter that I can provide, and setting it to zero is probably the right solution for my use case most of the time.
I do think being able to tell all of my outdated dependencies is a great feature, but updating those requires considerably more effort than updating my direct dependencies.
I think that being able to visually distinguish direct dependencies from indirect would be nice, although I guess that's anything without a ->
. There's just something about the current display that's overwhelming.
I don't know that anything I've said here is useful or actionable. Consider this unsolicited user feedback and feel free to close it as you see fit πΈ
To reproduce:
Cargo.toml:
[package]
name = "dep-test"
version = "0.1.0"
[dependencies]
handlebars = { version = "0.25", features = ["serde_type"] }
$ cargo outdated -R
error: Package `handlebars v0.29.1` does not have these features: `serde_type`
When I run cargo outdated
in a project with at least one dependency, it fails with the following error:
Checking for SemVer compatible updates...error: Failed to run 'cargo update' with error 'did not exit successfully'
When I run cargo update
, ~/.cargo/bin/cargo update
, or ~/.rustup/toolchains/nightly-x86_64-pc-windows-msvc/bin/cargo update
, they're successful.
Hi there!
I initially asked this question on SO. The user "Pyfish" wrote a script to do some rudimentary checking (see the his/her answer). I thought it would be awesome to have something like that integrated in a tool and I think your tool comes closest to what I want.
So my feature request: check if there is a wildcard dependency in the dependency graph and emit a warning for every wildcard found.
I'm running cargo outdated
against https://github.com/dimbleby/iron-hmac/tree/update-dependencies (at 3fea6b1e). Here's an example in which an intermediate run of cargo outdated -w
causes cargo outdated
to change its mind:
$ cargo outdated
Name Project Compat Latest Kind Platform
---- ------- ------ ------ ---- --------
iron 0.5.1 --- 0.6.0 Normal ---
iron->conduit-mime-types 0.7.3 --- Removed Normal ---
iron->error 0.1.9 --- Removed Normal ---
iron->lazy_static 0.2.9 --- Removed Normal ---
$ cargo outdated -w
iron-hmac
================
Name Project Compat Latest Kind Platform
---- ------- ------ ------ ---- --------
conduit-mime-types 0.7.3 --- Removed Normal ---
error 0.1.9 --- Removed Normal ---
iron 0.5.1 --- 0.6.0 Normal ---
lazy_static 0.2.9 --- Removed Normal ---
$ cargo outdated
Name Project Compat Latest Kind Platform
---- ------- ------ ------ ---- --------
conduit-mime-types->rustc-serialize 0.3.24 --- Removed Normal ---
error->traitobject 0.1.0 --- Removed Normal ---
error->typeable 0.1.2 --- Removed Normal ---
iron 0.5.1 --- 0.6.0 Normal ---
iron->conduit-mime-types 0.7.3 --- Removed Normal ---
iron->error 0.1.9 --- Removed Normal ---
iron->lazy_static 0.2.9 --- Removed Normal ---
All of the above miss various other things that are also outdated. eg hyper was never mentioned, but there's definitely a dependency on an old version:
$ grep "\"hyper " Cargo.lock
"hyper 0.11.6 (registry+https://github.com/rust-lang/crates.io-index)",
"hyper 0.11.6 (registry+https://github.com/rust-lang/crates.io-index)",
"hyper 0.10.13 (registry+https://github.com/rust-lang/crates.io-index)",
"hyper 0.11.6 (registry+https://github.com/rust-lang/crates.io-index)",
I'm at version 0.6.3:
$ cargo outdated --version
cargo-outdated v0.6.3
Print out a tree, like cargo-tree
It may be better to have another intermediate struct so that trees, JSONs can be built based on it.
Hi,
It seems that private dependencies with an ssh url cause a segmentation fault. I thought private dependencies wasn't supported but I checked with https urls and it works fine.
[dependencies]
dummy1 = { git="ssh://[email protected]/klefevre/dummy.git" } // make crash cargo-outdated
dummy2 = { git="https://github.com/klefevre/dummy.git" } // works
Cargo.toml
:
[dependencies]
clap = "2.19.0"
cargo update; cargo outdated
:
Updating registry `https://github.com/rust-lang/crates.io-index`
Checking for SemVer compatible updates...Done
Checking for the latest updates...Done
The following dependencies have newer versions available:
Name Project Ver SemVer Compat Latest Ver
clap 2.20.0 -- 2.19.3
clap->libc 0.2.18 -- 0.2.20
It's been mentioned in #51 and in rust-lang/cargo#4309 that the default behaviour should be to limit the output the direct dependencies. Since cargo-outdated
has already a -d
flag, it should be as simple as defaulting it to 1
It would be nice to provide a flag to view outdated dependencies for the entire workspace.
Clone the repository at https://github.com/sdroege/gstreamer-rs, run cargo update in the root and then run cargo outdated. It fails like below.
This is with cargo 0.22 and cargo outdated 0.6.0.
$ env RUST_BACKTRACE=1 cargo outdated -w
thread 'main' panicked at 'BUG: update() must be called before query()', /checkout/src/libcore/option.rs:819:4
stack backtrace:
0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::panicking::default_hook::{{closure}}
at /checkout/src/libstd/sys_common/backtrace.rs:71
at /checkout/src/libstd/sys_common/backtrace.rs:60
at /checkout/src/libstd/panicking.rs:381
2: std::panicking::rust_panic_with_hook
at /checkout/src/libstd/panicking.rs:397
at /checkout/src/libstd/panicking.rs:611
3: std::panicking::begin_panic
at /checkout/src/libstd/panicking.rs:572
4: std::panicking::begin_panic_fmt
at /checkout/src/libstd/panicking.rs:522
5: core::panicking::panic_fmt
at /checkout/src/libstd/panicking.rs:498
6: core::option::expect_failed
at /checkout/src/libcore/option.rs:819
7: <cargo::sources::git::source::GitSource<'cfg> as cargo::core::registry::Registry>::query
8: cargo::core::registry::Registry::query_vec
9: cargo_outdated::cargo_ops::temp_project::TempProject::find_update
10: cargo_outdated::cargo_ops::temp_project::TempProject::update_version_and_feature
11: cargo_outdated::execute
12: cargo_outdated::main
13: main
14: __libc_start_main
15: _start
This happens whenever I run cargo-outdated
in the Rust repository's src directory.
Rust 1.20.
When I try to build with the debug feature, the build fails with the following errors:
$ cargo build --features debug
Compiling cargo-outdated v0.5.1 (file:///C:/Users/kraaimx/src/cargo-outdated)
error[E0433]: failed to resolve. Maybe a missing `extern crate term;`?
--> src\macros.rs:17:50
|
17 | $config.shell().say(format!($($arg)*), ::term::color::WHITE)?
| ^^^^ Maybe a missing `extern crate term;`?
|
::: src\cargo_ops\elaborate_workspace.rs
|
152 | / debug!(
153 | | config,
154 | | "UPDATE, self: {:?}, key: {:?}, status: {:?}\n",
155 | | self_pkg.package_id(),
156 | | pkg_status_key,
157 | | pkg_status
158 | | );
| |__________- in this macro invocation
error[E0433]: failed to resolve. Maybe a missing `extern crate term;`?
--> src\macros.rs:17:50
|
17 | $config.shell().say(format!($($arg)*), ::term::color::WHITE)?
| ^^^^ Maybe a missing `extern crate term;`?
|
::: src\cargo_ops\elaborate_workspace.rs
|
165 | / debug!(
166 | | config,
167 | | "LOOP, parent: {:?}, self: {:?}, compat: {:?}, latest: {:?}\n",
168 | | parent,
... |
171 | | latest_pkg
172 | | );
| |__________- in this macro invocation
error[E0433]: failed to resolve. Maybe a missing `extern crate term;`?
--> src\macros.rs:17:50
|
17 | $config.shell().say(format!($($arg)*), ::term::color::WHITE)?
| ^^^^ Maybe a missing `extern crate term;`?
|
::: src\cargo_ops\elaborate_workspace.rs
|
202 | / debug!(
203 | | config,
204 | | "NEXT, next_self: {:?}, next_compat: {:?}, next_latest: {:?}\n",
205 | | next_self,
206 | | next_compat,
207 | | next_latest
208 | | );
| |______________- in this macro invocation
error[E0433]: failed to resolve. Maybe a missing `extern crate term;`?
--> src\macros.rs:14:41
|
14 | $config.shell().say($message, ::term::color::WHITE)?
| ^^^^ Maybe a missing `extern crate term;`?
|
::: src\main.rs
|
241 | debug!(config, format!("options: {:?}", options));
| -------------------------------------------------- in this macro invocation
error[E0599]: no method named `say` found for type `std::cell::RefMut<'_, cargo::core::Shell>` in the current scope
--> src\macros.rs:14:25
|
14 | $config.shell().say($message, ::term::color::WHITE)?
| ^^^
|
::: src\main.rs
|
241 | debug!(config, format!("options: {:?}", options));
| -------------------------------------------------- in this macro invocation
error[E0599]: no method named `say` found for type `std::cell::RefMut<'_, cargo::core::Shell>` in the current scope
--> src\macros.rs:17:25
|
17 | $config.shell().say(format!($($arg)*), ::term::color::WHITE)?
| ^^^
|
::: src\cargo_ops\elaborate_workspace.rs
|
152 | / debug!(
153 | | config,
154 | | "UPDATE, self: {:?}, key: {:?}, status: {:?}\n",
155 | | self_pkg.package_id(),
156 | | pkg_status_key,
157 | | pkg_status
158 | | );
| |__________- in this macro invocation
error[E0599]: no method named `say` found for type `std::cell::RefMut<'_, cargo::core::Shell>` in the current scope
--> src\macros.rs:17:25
|
17 | $config.shell().say(format!($($arg)*), ::term::color::WHITE)?
| ^^^
|
::: src\cargo_ops\elaborate_workspace.rs
|
165 | / debug!(
166 | | config,
167 | | "LOOP, parent: {:?}, self: {:?}, compat: {:?}, latest: {:?}\n",
168 | | parent,
... |
171 | | latest_pkg
172 | | );
| |__________- in this macro invocation
error[E0599]: no method named `say` found for type `std::cell::RefMut<'_, cargo::core::Shell>` in the current scope
--> src\macros.rs:17:25
|
17 | $config.shell().say(format!($($arg)*), ::term::color::WHITE)?
| ^^^
|
::: src\cargo_ops\elaborate_workspace.rs
|
202 | / debug!(
203 | | config,
204 | | "NEXT, next_self: {:?}, next_compat: {:?}, next_latest: {:?}\n",
205 | | next_self,
206 | | next_compat,
207 | | next_latest
208 | | );
| |______________- in this macro invocation
error: aborting due to 8 previous errors
error: Could not compile `cargo-outdated`.
To learn more, run the command again with --verbose.
The package quickcheck version 0.4.2 is yanked which causes error:
error: no matching version `^0.4.2` found for package `quickcheck` (required by `dummylib`)
location searched: registry https://github.com/rust-lang/crates.io-index
versions found: 0.4.1, 0.4.0, 0.3.2, ...
Example Cargo.toml
:
[package]
name = "dummybin"
[dependencies]
dummylib = { path = "../dummylib" }
[dev-dependencies]
dummylib = { path = "../dummylib", features = ["quickcheck"] }
$ cargo outdated
warning: Feature quickcheck of package dummylib has been obsolete in version 0.1.0
warning: Feature quickcheck of package dummylib has been obsolete in version 0.1.0
error: no matching version `^0.4.2` found for package `quickcheck` (required by `dummylib`)
location searched: registry https://github.com/rust-lang/crates.io-index
versions found: 0.4.1, 0.4.0, 0.3.2, ...
The "feature has been obsolete" warning have their own issue: #100.
The logic in elaborate_workspace.rs
is not feature-aware.
It says there is a dependency on rustc-serialize, which no longer is the case. Perhaps just remove it?
Here is an example repository: https://github.com/mehcode/cargo-outdated-bug-patch
β― cargo +nightly outdated
error: Direct dependency reqwest not found for package cargo_outdated_bug
This is using the most recent cargo-outdated
installed via cargo install cargo-outdated
.
β― rustc --version
rustc 1.21.0 (3b72af97e 2017-10-09)
β― cargo --version
cargo 0.22.0 (3423351a5 2017-10-06)
Since cargo
is using docopt
It would be cool if the output is colorized :)
Here is an idea:
1.2.4 -> 1.3.7
the 3.7
would be orange)1.2.4 -> 1.3.7
the 1
would be green)Version: 0.5.1
This Cargo.toml always fail with the following error:
error: no matching package named `pest_derive` found (required by `tera`)
location searched: registry https://github.com/rust-lang/crates.io-index
version required: *
Path.join()
is slightly faster and more idiomatic. Low priority tho.
#![feature(test)]
extern crate test;
use std::path::{Path, PathBuf};
pub fn format_path() -> PathBuf {
PathBuf::from(format!("{}/{}", "/etc", "systemd/"))
}
pub fn join_path() -> PathBuf {
Path::new("/etc").join("systemd/")
}
#[cfg(test)]
mod tests {
use super::*;
use test::Bencher;
#[bench]
fn bench_format_path(b: &mut Bencher) {
b.iter(|| format_path());
}
#[bench]
fn bench_join_path(b: &mut Bencher) {
b.iter(|| join_path());
}
}
β cargo bench
Finished release [optimized] target(s) in 0.0 secs
Running target/release/deps/hello_world-f29c263b9d11d26d
running 2 tests
test tests::bench_format_path ... bench: 118 ns/iter (+/- 14)
test tests::bench_join_path ... bench: 90 ns/iter (+/- 4)
test result: ok. 0 passed; 0 failed; 0 ignored; 2 measured; 0 filtered out
It would show only deps with a Latest version which is not compatible with SemVer compat. It could be a good thing for libraries, to improve compatibility with other crates.
I have a crate that depends on chrono, diesel, uuid, and serde. These each need certain features enabled in order to work together, e.g. from Crate.toml
(simplified):
[dependencies.diesel]
features = [
"postgres",
"chrono",
]
version = "0.16.0"
[dependencies.chrono]
features = ["serde"]
version = "0.4"
[dependencies]
serde = "1.0.0"
serde_derive = "1.0.0"
serde_json = "1.0.0"
With cargo-outdated 0.6.2, running cargo outdated
on this crate produces the following warnings:
warning: Feature serde of package chrono has been obsolete in version 0.4.0
warning: Feature chrono of package diesel has been obsolete in version 0.16.0
warning: Feature uuid of package diesel has been obsolete in version 0.16.0
warning: Feature serde_json of package diesel has been obsolete in version 0.16.0
warning: Feature uuid of package rocket_contrib has been obsolete in version 0.3.3
warning: Feature serde of package uuid has been obsolete in version 0.5.1
However, removing these features causes the crate to fail to compile. cargo outdated
should not be producing these warnings if the feature exists on the target version of the dependency.
Running cargo outdated
multiple times can produce a different number of outdated dependencies:
$ cargo outdated
Checking for SemVer compatible updates...Done
Checking for the latest updates...Done
The following dependencies have newer versions available:
Name Project Ver SemVer Compat Latest Ver
handlebars->quick-error 0.1.4 -- 0.2.2
quick-error 0.2.2 0.1.4 --
$ cargo outdated
Checking for SemVer compatible updates...Done
Checking for the latest updates...Done
The following dependencies have newer versions available:
Name Project Ver SemVer Compat Latest Ver
handlebars->quick-error 0.1.4 0.2.2 0.2.2
The Cargo.*
files which produce this output can be found in this gist.
Maybe we could publish some dummy crates so that some proper test cases can be written.
And actually I am still a bit unsure about the behaviour of cargo update
in some scenarios, e.g. how it deals with yanked dependencies.
It would be nice to have cargo outdated
work in the global environment and check for updates on the installed cargo binaries when not in a project directory.
Mentioned here by @SergioBenitez
Please provide --manifest-path
, so I can automate checking with my Makefile
in imag.
π
Here's output from one of my projects (c-ares-resolver
):
$ cargo outdated
Name Project Ver SemVer Compat Latest Ver
bytes->byteorder 1.1.0 RM RM
bytes->iovec 0.1.0 RM RM
conv->custom_derive 0.1.7 RM RM
dns-parser 0.7.0 RM RM
dns-parser->byteorder 0.4.2 RM RM
dns-parser->matches 0.1.6 RM RM
dns-parser->quick-error 1.2.0 RM RM
iovec->libc 0.2.29 RM RM
iovec->winapi 0.2.8 RM RM
kernel32-sys->winapi 0.2.8 RM RM
kernel32-sys->winapi-build 0.1.1 RM RM
magenta->conv 0.3.3 RM RM
magenta->magenta-sys 0.1.1 RM RM
magenta-sys->bitflags 0.7.0 RM RM
mio->iovec 0.1.0 RM RM
mio->kernel32-sys 0.2.2 RM RM
mio->lazycell 0.5.1 RM RM
mio->libc 0.2.29 RM RM
mio->log 0.3.8 RM RM
mio->magenta 0.1.1 RM RM
mio->magenta-sys 0.1.1 RM RM
mio->miow 0.2.1 RM RM
mio->net2 0.2.30 RM RM
mio->slab 0.3.0 RM RM
mio->winapi 0.2.8 RM RM
miow->kernel32-sys 0.2.2 RM RM
miow->net2 0.2.30 RM RM
miow->winapi 0.2.8 RM RM
miow->ws2_32-sys 0.2.1 RM RM
net2->cfg-if 0.1.2 RM RM
net2->kernel32-sys 0.2.2 RM RM
net2->libc 0.2.29 RM RM
net2->winapi 0.2.8 RM RM
net2->ws2_32-sys 0.2.1 RM RM
tokio-core 0.1.9 RM RM
tokio-core->bytes 0.4.4 RM RM
tokio-core->futures 0.1.14 RM RM
tokio-core->iovec 0.1.0 RM RM
tokio-core->log 0.3.8 RM RM
tokio-core->mio 0.6.10 RM RM
tokio-core->scoped-tls 0.1.0 RM RM
tokio-core->slab 0.3.0 RM RM
tokio-core->tokio-io 0.1.2 RM RM
tokio-io->bytes 0.4.4 RM RM
tokio-io->futures 0.1.14 RM RM
tokio-io->log 0.3.8 RM RM
winapi 0.2.8 RM RM
ws2_32-sys 0.2.1 RM RM
ws2_32-sys->winapi 0.2.8 RM RM
ws2_32-sys->winapi-build 0.1.1 RM RM
#46 already has me covered for "I've no idea what RM even means", this issue says "surely that's not right?"
Running the command on my project that has clap 2.24.2
in my Cargo.lock
, I get the following output.
Checking for SemVer compatible updates...Done
Checking for the latest updates...Done
The following dependencies have newer versions available:
Name Project Ver SemVer Compat Latest Ver
clap 2.24.2 -- 2.25.0
I would expect the SemVer Compat column to contain "2.25.0".
This project is cool! Now that cargo install
works, if this was published as a crate, we could use cargo install cargo-outdated
to install the project.
This is related to #50.
If we create two local cargo projects under the same working directory foo
and bar
by running cargo new foo
and cargo new bar
, and having bar
depending on foo
by including the following in the Cargo.toml
of bar
:
[dependencies.foo]
version = "0.1"
path = "../foo"
It will compile successfully using cargo build
. cargo outdated
will throw an error:
cargo outdated
error: failed to load source for a dependency on `foo`
Caused by:
Unable to update file:///tmp/foo
Caused by:
failed to read `/tmp/foo/Cargo.toml`
Caused by:
No such file or directory (os error 2)
I am using cargo-outdated 0.6.1
.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.