paketo-buildpacks / go-mod-vendor Goto Github PK
View Code? Open in Web Editor NEWA Cloud Native Buildpack for Go Modules
License: Apache License 2.0
A Cloud Native Buildpack for Go Modules
License: Apache License 2.0
This codebase should be rewritten to take advantage of the new packit library.
If the go.mod
file does not have any required packages, the mod-cache
layer is empty and breaks caching:
go.mod
module example.com/mymodule
go 1.13
Build output:
$pack build example.com/myapp --buildpack gcr.io/paketo-buildpacks/go --no-pull
===> DETECTING
[detector] paketo-buildpacks/go-dist 0.0.193
[detector] paketo-buildpacks/go-mod-vendor 0.0.148
[detector] paketo-buildpacks/go-build 0.0.15
===> ANALYZING
[analyzer] Previous image with name "example.com/myapp:latest" not found
===> RESTORING
===> BUILDING
[builder] Go Distribution Buildpack 0.0.193
[builder] Resolving Go version
[builder] Candidate version sources (in priority order):
[builder] <unknown> -> ""
[builder] <unknown> -> ""
[builder]
[builder] Selected Go version (using <unknown>): 1.14.6
[builder]
[builder] Executing build process
[builder] Installing Go 1.14.6
[builder] Completed in 28.244s
[builder]
[builder] Go Mod Vendor Buildpack 0.0.148
[builder] Executing build process
[builder] Running 'go mod vendor'
[builder] Completed in 79ms
[builder]
[builder] Go Build Buildpack 0.0.15
[builder] Executing build process
[builder] Running 'go build -o /layers/paketo-buildpacks_go-build/targets/bin -buildmode pie .'
[builder] Completed in 31.047s
[builder]
[builder] Assigning launch processes
[builder] web: /layers/paketo-buildpacks_go-build/targets/bin/go-online
===> EXPORTING
[exporter] Adding layer 'paketo-buildpacks/go-build:targets'
[exporter] Adding 1/1 app layer(s)
[exporter] Adding layer 'launcher'
[exporter] Adding layer 'config'
[exporter] Adding label 'io.buildpacks.lifecycle.metadata'
[exporter] Adding label 'io.buildpacks.build.metadata'
[exporter] Adding label 'io.buildpacks.project.metadata'
[exporter] *** Images (f8168ad499d0):
[exporter] example.com/myapp:latest
[exporter] Adding cache layer 'paketo-buildpacks/go-dist:go'
[exporter] Warning: Failed to export cache: failed to cache layer 'paketo-buildpacks/go-mod-vendor:mod-cache' because it has no contents
Successfully built image example.com/myapp
If there is nothing in the layer, we should remove it.
Update GitHub config workflow failed.
After the buildpack finishes its integration test there are still containers left running on the machine. The integration tests should fully clean themselves up.
We should looking into adding support for apps that have multiple go.mod files.
Helpful links:
Acceptance
pack build
should succeed when building a multi-module golang app using go modules
Push Buildpackage workflow failed.
I'm trying to build a vendored Go app that uses go modules, and seeing the following error.
pack build online-mod-app1 --buildpack gcr.io/paketo-buildpacks/go-dist --buildpack gcr.io/paketo-buildpacks/go-mod-vendor --buildpack gcr.io/paketo-buildpacks/go-build -v
Pulling image gcr.io/paketo-buildpacks/builder:full-cf
full-cf: Pulling from paketo-buildpacks/builder
Digest: sha256:a644524b74ce5e6f6aa061e4ca3da49c8ac763ba2a504accafbd3846a4b49505
Status: Image is up to date for gcr.io/paketo-buildpacks/builder:full-cf
Selected run image mirror index.docker.io/paketobuildpacks/run:full-cnb-cf
Pulling image index.docker.io/paketobuildpacks/run:full-cnb-cf
full-cnb-cf: Pulling from paketobuildpacks/run
Digest: sha256:5bfb17205e2f528b91e10db7adca72c9e1689e189fad23cf5ab8793fc1b7201e
Status: Image is up to date for paketobuildpacks/run:full-cnb-cf
Pulling image gcr.io/paketo-buildpacks/go-dist
latest: Pulling from paketo-buildpacks/go-dist
d66019a3339b: Pull complete
Digest: sha256:9d13aca199d38cbd95d73b97f05dd354cb2ffaf1732c3349a9fbe63042b00bac
Status: Downloaded newer image for gcr.io/paketo-buildpacks/go-dist:latest
Pulling image gcr.io/paketo-buildpacks/go-mod-vendor
latest: Pulling from paketo-buildpacks/go-mod-vendor
Digest: sha256:e36c7b2a942291afffe28252fd41a5261486bec8e4eaa6970a1ce827e3566b22
Status: Image is up to date for gcr.io/paketo-buildpacks/go-mod-vendor:latest
Pulling image gcr.io/paketo-buildpacks/go-build
latest: Pulling from paketo-buildpacks/go-build
ef125ae8f7da: Pull complete
Digest: sha256:033f59236c80a068561c0a56bca9c55103f9bf57b2052d2beffc183536c7cdba
Status: Downloaded newer image for gcr.io/paketo-buildpacks/go-build:latest
Adding buildpack paketo-buildpacks/go-dist version 0.0.193 to builder
Adding buildpack paketo-buildpacks/go-mod-vendor version 0.0.148 to builder
Adding buildpack paketo-buildpacks/go-build version 0.0.15 to builder
Setting custom order
Creating builder with the following buildpacks:
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
Using build cache volume pack-cache-cc3907c23dda.build
===> DETECTING
======== Output: paketo-buildpacks/[email protected] ========
failed
======== Results ========
pass: paketo-buildpacks/[email protected]
fail: paketo-buildpacks/[email protected]
pass: paketo-buildpacks/[email protected]
ERROR: No buildpack groups passed detection.
ERROR: Please check that you are running against the correct path.
ERROR: failed to detect: failed to detect: no buildpacks participating
ERROR: failed with status code: 1
Can reproduce with the following fixture https://github.com/paketo-buildpacks/go-mod-vendor/tree/master/integration/testdata/default and vendoring the app beforehand.
What version of the buildpack you are using?
org.cloudfoundry.go-mod- 0.0.29
What did you expect to happen?
I expected the built binary to be on the pack at launch.
What was the actual behavior?
The app binary is in /layers/org.cloudfoundry.go-mod/app-binary/build-init instead of /layers/org.cloudfoundry.go-mod/app-binary/bin/build-init
Can you provide a sample app?
http://github.com/pivotal/kpack
Create Draft Release workflow failed.
What version of Cloud Foundry and CF CLI are you using? (i.e. What is the output of running cf curl /v2/info && cf version
?
N/A - Was testing the go-mod
using kpack
What version of the buildpack you are using?
[email protected]
If you were attempting to accomplish a task, what was it you were attempting to do?
Rebuild an image using kpack where caching was enabled
What did you expect to happen?
The image would be re-built using the cached layers
What was the actual behavior?
The lifecycle of CNB fails at restore
as the layer tar can be uncompressed
Restoring cached layer 'org.cloudfoundry.go-mod:go-mod'
Error: failed to restore: mkdir /layers/org.cloudfoundry.go-mod/go-mod/pkg/mod/github.com/bstick12/[email protected]/.circleci: permission denied
The previous layer is correctly used from cache
Restoring cached layer 'org.cloudfoundry.go-compiler:ac2a6efcc1f5ec8bdc0db0a988bb1d301d64b6d61b7e8d9e42f662fbb75a2b9b'
Restoring cached layer 'org.cloudfoundry.go-compiler:go'
The problem lies with the go module package paths. The package directories are not writeable. Apparently this is by design as discussed in golang/go#27161 and golang/go#27455 (comment)
File: /layers/org.cloudfoundry.go-mod/go-mod/pkg/mod/github.com/bstick12/[email protected]/
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 6ch/108d Inode: 300555 Links: 4
Access: (0500/dr-x------) Uid: ( 1000/ cnb) Gid: ( 1000/ cnb)
This permission is preserved in the tarball
dr-x------ 1000/1000 0 1980-01-01 00:00 /layers/org.cloudfoundry.go-mod/go-mod/pkg/mod/github.com/bstick12/[email protected]
d
Since without a change to the tar or untaring process for this buildpack the caching process will break. Would be possible to disable caching.
Can you provide a sample app?
The behaviour should be the same for any go application that use go modules.
Please confirm where necessary:
Go get update workflow failed.
Please take a look to ensure CVE patches can be released. (cc @pivotal-cf/commercial-buildpacks).
Trying to build a go app that has vendored dependencies with go 1.16. The go.mod
file has:
go 1.16
This should build the app image with go 1.16
This buildpack failed to detect and the go-dist buildpack expected either BP_GO_VERSION
to be set in the environment or through the buildpack.yml
(which is deprecated.) This means that a user needs to specify the version of go in an additional location than just using the go.mod
file to verify the version required.
===> BUILDING
[builder] Paketo Go Distribution Buildpack 0.3.0
[builder] Resolving Go version
[builder] Candidate version sources (in priority order):
[builder] <unknown> -> ""
[builder]
[builder] Selected Go version (using <unknown>): 1.15.8
[builder]
[builder] Reusing cached layer /layers/paketo-buildpacks_go-dist/go
pack
, kpack
, tekton
buildpacks plugin, etc.) are youpack latest cli
go buildpack v0.4.0
pack inspect-builder <builder>
?custom but not relevant
buildpack.yml
,nginx.conf
, etc.)?no buildpack config
Currently the entire gocache is stored in one layer. The same is true for the go modules. We may be able to improve layer caching/restoring performance if we slice the gocache and go mod layers into many separate layers. I don't have any actual evidence that this will improve performance, but it makes sense on a conceptual level as very few things will change in the modules and cache between builds. Finally, the layout of the gocache and the go modules directories are already setup for convenient slicing because they contain well distributed sub-directories.
Approve bot PR workflow failed.
Using master of go-mod-cnb
master branch
Build source code using the go-mod-cnb buildpack where a module references code from a private git repo.
I expected some input or method to provide credentials to the buildpack to build the container image.
We got the following error as when git tried to fetch from a private repo, it wanted to prompt the user for a username and password to access, but couldn't.
[builder] go: finding github.com/cmccarthy101/test10 v0.0.0-20190508160027-f70a194aee79
[builder] go: github.com/cmccarthy101/[email protected]: git fetch -f origin refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in /layers/org.cloudfoundry.go-mod/go-mod/pkg/mod/cache/vcs/1c0e1ed356a540e8b5b7244633737b2ebac6042801011dba950572c2525b76c3: exit status 128:
[builder] fatal: could not read Username for 'https://github.com': terminal prompts disabled
https://github.com/cmccarthy101/test11.git
// @BenChapman
As of Go 1.15 user could specify GOMODCACHE to indicate a location of the go mod cache
golang/go#31283
We should update our code here to use that environment variable.
Line 94 in 412384b
We should support building Go apps with version defined in the go.mod file as this is fairly standard practice.
Acceptance
GIVEN I have a Go app that uses Go Modules
AND it sets the version of Go to use in the go.mod
file
WHEN I pack build
it
THEN I should see that the app is built with the go version defined in go.mod
Problem
When an image is created with go src code that does not contain a main
package, the build phase logs the following:
[builder] Running `go install`
[builder] rename /layers/paketo-buildpacks_go-mod/go-mod/bin/helloworldgo /layers/
paketo-buildpacks_go-mod/app-binary/bin/helloworldgo: no such file or directory
[builder] ERROR: failed to build: exit status 103
ERROR: failed with status code: 7
This doesn't tell the user that the problem lies in the source code and not in the buildpack
Suggestion
Log an error message to the effect of failed to create a valid executable.
Requests for being able to use private repos as go modules has come up a couple times and probably something we should consider. Here's a recent question from @cirocosta around this:
is it correct to say that the credentials used for the
prepare
step are not injected into thebuild
step?
the use case: i’ve got a private repo that depends on other private repos (via go modules) and I currently don’t vendor them all into the first -build
currently seems unable to fetch those private dependencies
I'm filing this here as the specific request is around go modules, but likely that there's a solution for this across all buildpacks.
Publish All Draft Releases workflow failed.
0.0.58
I'm trying to see the contents of my go.mod file attached to the image for OSL verification
The module information was somehow passed along
± zm |master U:1 ?:1 ✗| → inspect-bom gcr.io/cncf-buildpacks-ci/pm/github-actions-automate-projects:sandbox | jq
{
"bom": [
{
"name": "go",
"version": "1.13.4",
"metadata": {
"licenses": [],
"name": "Go",
"sha256": "692d17071736f74be04a72a06dab9cac1cd759377bd85316e52b2227604c004c",
"stacks": [
"io.buildpacks.stacks.bionic",
"org.cloudfoundry.stacks.tiny"
],
"uri": "https://dl.google.com/go/go1.13.4.linux-amd64.tar.gz"
},
"buildpack": {
"id": "org.cloudfoundry.go-compiler",
"version": "0.0.55"
}
},
{
"name": "",
"version": "",
"metadata": null,
"buildpack": {
"id": "org.cloudfoundry.go-compiler",
"version": "0.0.55"
}
},
{
"name": "",
"version": "",
"metadata": null,
"buildpack": {
"id": "org.cloudfoundry.go-mod",
"version": "0.0.58"
}
}
],
"buildpacks": [
{
"id": "org.cloudfoundry.go-compiler",
"version": "0.0.55"
},
{
"id": "org.cloudfoundry.go-mod",
"version": "0.0.58"
}
],
"launcher": {
"version": "0.5.0",
"source": {
"git": {
"repository": "https://github.com/buildpack/lifecycle",
"commit": "f0a279f"
}
}
}
}
inspect-bom is a function
inspect-bom ()
{
image=$1;
docker inspect "${image}" | jq '.[].Config.Labels | .["io.buildpacks.build.metadata"] ' | jq -r
}
@brayanhenao and I are exploring creating a Bill Of Materials (BOM) buildpack for golang, similar in principle to: https://github.com/paketo-buildpacks/node-module-bom
This new buildpack would require go mod
, and could probably benefit from the vendor
directory being pre-populated during the build
phase, as it will likely populate that directory if it hasn't already been done.
Both of those two things point to the BOM buildpack having a dependency on this buildpack, but currently I do not believe it is possible to express this relationship because this buildpack does not provide any dependencies for other buildpacks to detect
.
One of the challenges I'm having with this idea is that I can't think of any meaningful information that this buildpack could provide that the BOM buildpack would actually use. All the BOM buildpack really needs to know is whether the go-mod-vendor buildpack passed its detect
phase, and it could benefit from the go-mod-vendor buildpack running its build
phase before it analyses the dependencies and produces a BOM.
I may be misunderstanding the way to represent dependent relationships between buildpacks, though, so please correct me if my understanding is wrong!
running cf curl /v2/info && cf version
?
pack cli v0.1.0 (git sha: e1793ab9fc3d172a416183ef3df20daf089eba19)
v0.2.0
N/A
Source code should not be included in the run container once the Go code has been compiled
Source code was included in the run container once the Go code was compiled
Any app will do
/cc @BenChapman
$ docker run -ti cloudfoundry/cnb:cflinuxfs3 bash -euc "ls /buildpacks/org.cloudfoundry.go-mod/"
0.0.9 latest
Sorry for using issues for my own learning.
Why is 0.0.15 the latest version of this buildpack (7 days ago), but https://github.com/cloudfoundry/go-mod-cnb/releases/tag/v0.0.9 from 26 days ago is the version in the builder?
Currently the buildpack runs go mod graph
to check and see if there are any dependencies present in the go.mod
file and if the file is empty we skip running go mod vendor
. This however has been reported by users to cause a slow rebuild as the go mod graph itself can take upwards of a minute.
I think that we should remove the go mod graph
check and just run go mod vendor
if there is a go.mod
file present in the workspace. This may be a minor penalty for user that have a go.mod
file with no packages but ultimately the go mod vendor
command does not fail if there are no packages and it outputs a message similar to what we output on our own scan.
I think that there is a very little reason not to do this. It will simplify the build logic and will have almost identical output to users that have go.mod
files with no packages present.
What were you attempting to do?
I was trying to build an app with go 1.12
in my go.mod
file.
What did you expect to happen?
I expected it to build with the language features present in Go 1.12 as outlined in the documentation.
What was the actual behavior? Please provide log output, if possible.
It prints that it cannot find a 1.12
version of Go.
Paketo Go Distribution Buildpack 0.2.6
Resolving Go version
Candidate version sources (in priority order):
go.mod -> "1.12.*"
<unknown> -> ""
failed to satisfy "go" dependency version constraint "1.12.*": no compatible versions. Supported versions are: [1.14.12, 1.14.13, 1.15.5, 1.15.6]
ERROR: failed to build: exit status 1
What platform (pack
, kpack
, tekton
buildpacks plugin, etc.) are you
using? Please include a version.
pack 0.15.1+git-79adc30.build-1660
What buildpacks are you using? Please include versions.
Can you provide a sample app or relevant configuration (buildpack.yml
,
nginx.conf
, etc.)?
module example-app
go 1.12
Pivotal provides the GitBot service to synchronize pull requests and/or issues made against public GitHub repos with Pivotal Tracker projects. This service does not track individual commits.
If you are a Pivotal employee, you can configure Gitbot to sync your GitHub repo to your Pivotal Tracker project with a pull request. An ask+cf@ ticket is the fastest way to get write access if you get a 404 to the config repo.
If you do not want have pull requests and/or issues copied from GitHub to Pivotal Tracker, you do not need to take any action.
If there are any questions, please reach out to [email protected].
In a corporate setting we use Artifactory to as a pull through for go packages. In order for it to work GOPROXY, GONOPROXY, GOSUMDB, GONOSUMDB, and GOPRIVATE need to be configurable.
Set GOPROXY, GONOPROXY, GOSUMDB, GONOSUMDB, and GOPRIVATE in a build pipeline/locally and run pack build image
with the env variables seamlessly passing to go mod vendor
.
In a corporate setting network requests can be man-in-the-middled by security software. Requests for go packages need to use go_proxy
In order to implement the Go re-architecture RFC we should rename this buildpack to go-mod-vendor
. ID should also be changed to go-mod-vendor
.
After this change is made and the buildpack is packit re-written, ordering in the language family Go Buildpack should be something like:
[[order]]
[[order.group]]
id = "go-dist"
[[order.group]]
id = "go-mod-vendor"
[[order.group]]
id = "go-build"
..........................
Starting with go 1.21, there is an optional entry in go.mod
for toolchain
, and an associated environment variable GOTOOLCHAIN
. This is part of a larger change in go 1.21 around toolchains and minimum go versions. See documentation and the blog post.
This issue is to capture thoughts around what we might want to do with this new information. If we identify actionable features we can link them here.
Based on my understanding, I don't think there's too much the buildpack can or should do with this information, as the go toolchain itself processes this information and acts accordingly.
One thing we could choose to do could be fail-fast during Detect
if the requested go toolchain is greater than the available versions of go the buildpack provides. That could be contentious, however, as starting with go 1.21, the go toolchain will download the required version of golang automatically, and as a result Paketo Buildpacks could be viewed as unnecessarily restrictive. Of course, this automatic download wouldn't work in an offline environment, so the build will fail regardless of whether the failure is by the buildpack in Detect
or by the toolchain in Build
.
Its super common in the wild for -ldflags
to have more than just -X
, eg -s -w
and especially -
-extldflags -static. Could we support this? Or alternately, provide a config switch that would just add a handful of sane defaults like
clean: true->
-ldflags -s -wand
static: true->
-ldflags "-extldflags -static"`
If an app has multiple targets, then all of the targets will be built but, only the first target will actually be exported in the resulting image.
For example in an app with the following buildpack.yaml, only binaryone
will be in the resulting image.
go:
targets: ["./cmd/binaryone", "./cmd/binarytwo", "./cmd/binarythree"]
I think we can simplify the logic around Detect
failing if go.mod
is not present by leveraging the fs.Exists()
method in packit
. We would check the existence of the file first, returning early if it does not exist (or errors when trying to determine if the file exists), and then moving on to parsing it once we know it exists.
I'm happy to submit a PR for this if you agree.
Building a go+react app. The directory structure is such that the go.mod
file is at the root and there is a subdirectory called web
that contains the node stuff.
Builds after zero changes to be really fast.
Builds were slow and it seems generating the SBOM is where most of the time is spent (~28s):
Paketo Go Mod Vendor Buildpack 0.5.0
Checking module graph
Running 'go mod graph'
Completed in 752ms
Executing build process
Running 'go mod vendor'
Completed in 462ms
Generating SBOM for directory /workspace
Completed in 28.804s
When I run pack --sbom-output-dir /tmp
I can see that /tmp/sbom/build/paketo-buildpacks_go-mod-vendor/sbom.syft.json
contains all the node dependencies in addition to the go dependencies.
It looks like on this line the parameter to the sbom generator is pointing to entire workingDir
and I suppose I expect to be more specific like just go.mod
?
pack
, kpack
, tekton
buildpacks plugin, etc.) are youpack --version
0.24.0+git-79a40b7.build-3148
What version of the buildpack you are using?
master
If you were attempting to accomplish a task, what was it you were attempting to do?
Pass ldflags
with a version so that our binary could be built with version information. For example, -ldflags -X github.com/example.com/cmd.Version=1.2.3
What did you expect to happen?
The resulting image would have our app binary and the version reported by that app binary would be what was passed via ldflags
.
What was the actual behavior?
The version reported by the binary is never set.
Can you provide a sample app?
We are attempting to do this on github.com/pivotal/kpack
. The Version
is set in the file cmd/version.go
and the ldflags we pass in the buildpack.yaml
looks like the following:
"github.com.pivotal.kpack.cmd.Version": "1.2.3"
This bug was exposed after fixing the ldflags
behavior with PR #11
Please confirm where necessary:
Make sure all import statements are updated to point at the paketo-buildpacks org!
What version of Cloud Foundry and CF CLI are you using? (i.e. What is the output of running cf curl /v2/info && cf version
?
N/A
What version of the buildpack you are using?
v0.0.49
If you were attempting to accomplish a task, what was it you were attempting to do?
Build an app using the following command:
pack build myapp -e BP_GO_TARGETS="./cmd/app/" -p <local source code path>
What did you expect to happen?
The app builds correctly.
What was the actual behavior?
Fails with:
[builder] Running `go install`
[builder] rename /layers/org.cloudfoundry.go-mod/go-mod/bin /layers/org.cloudfoundry.go-mod/app-binary/bin: file exists
[builder] ERROR: failed to build: exit status 103
Can you provide a sample app?
I can if you need me to. It should be east to replicate. The broken logic is in mod.go setAppName().
Please confirm where necessary:
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.