jrieken / gulp-tsb Goto Github PK
View Code? Open in Web Editor NEWgulp plugin for incremental TypeScript building
License: MIT License
gulp plugin for incremental TypeScript building
License: MIT License
When I pass a sourceRoot value in the options, I expect to see it output in the .map files, like it does when I use tsc, but with gulp-tsb, I don't see it there which breaks the ability to have source files somewhere else from the map files.
I noticed that builder.ts
has a fair bit of async coordination, such as the workOnNext
function and the toBeEmitted
, toBeCheckedSyntactically
, and toBeCheckedSemantically
arrays.
I wrote prex originally as part of an internal test framework, and used it in the F12 developer tools. I published the package recently as an opportunity to discuss several of the primitives with TC39 (such as CancellationToken). The package adds a number of coordination primitives to simplify various existing patterns around asynchronous coordination, and the work is based primarily off of the thread/task coordination primitives found in .NET.
A few examples of some of the available primitives that could be beneficial include:
All of the primitives are built on top of, or to work with, ES6 native promises. They are especially useful when combined with async/await (available for --target ES6
currently, and for other script targets in the next TypeScript release).
It seems like this module doesn't work with gulp-sourcemap. That's OK, but that should be reflected in the README.
Hi, just wondering how you would avoid hardcoding the values in the gulpfile.js
file, so instead of the below compilation
would read all the files from the tsconfig.json
? Would also be nice if I could avoid the dest(...)
call as well somehow as this is in the config as well.
var tsb = require('gulp-tsb');
// create and keep compiler
var compilation = tsb.create({
target: 'es5',
module: 'commonjs',
declaration: false
});
gulp.task('build', function() {
return gulp.src('src/**/*.ts')
.pipe(compilation()) // <- new compilation
.pipe(gulp.dest(''));
});
Edit:
a. I also wonder why these gulp typescript tasks don't just simply delegate to the TypeScript compiler.
b. Is there any chance of merging intogulp-typescript
? As the latter seems to support what I was looking for, e.g., however the dest
is still there...
gulp.task('scripts', function() {
var tsResult = tsProject.src() // instead of gulp.src(...)
.pipe(ts(tsProject));
return tsResult.js.pipe(gulp.dest('release'));
});
Thank you,
I have an electron project where some files reference github-electron-main.d.ts and others reference github-electron-renderer.d.ts and when I compile with tsc, I don't get any errors. But, when I use gulp and gulp-tsb, I get:
Duplicate identifier 'export='."
Duplicate identifier 'export='."
reported once for each file. It looks like typescript's compiler supports this, but tsb somehow breaks the functionality.
It could defer to the TS compiler's built-in watching algorithms, this way it can watch all files in the project (including imports and configs) - not just those found via processing the input files list/includes/excludes.
It would also be the last public method to make the project into a full and complete vinyl provider, AFAIK.
Seeing this with "gulp watch" in VS Code. I wait until the full build is done and then I do a change anywhere in the workbench (e.g. console.log in workbench.ts). After that, almost a full build is triggered because gulp-tsb thinks the shape of lib.d.ts has changed:
[11:23:01] [tsb] time: 26158ms mem: 737MB Δ686
*** Finished with 0 errors.
*** Starting...
[11:23:59] [emit code] /Users/bpasero/Development/monaco/src/vs/workbench/browser/workbench.js
[11:23:59] [check syntax] /Users/bpasero/Development/monaco/node_modules/typescript/lib/lib.d.ts
[11:23:59] [check syntax] /Users/bpasero/Development/monaco/src/vs/workbench/browser/workbench.ts
[11:23:59] [check semantics] /Users/bpasero/Development/monaco/node_modules/typescript/lib/lib.d.ts
[11:23:59] [check semantics] /Users/bpasero/Development/monaco/src/vs/workbench/browser/workbench.ts
[11:23:59] [check semantics*] /Users/bpasero/Development/monaco/node_modules/typescript/lib/lib.d.ts is an internal module and it has changed shape -> check whatever hasn't been checked yet
[11:23:59] [check semantics] /Users/bpasero/Development/monaco/src/vs/workbench/services/files/node/watcher/win32/watcherService.ts
[11:23:59] [check semantics] /Users/bpasero/Development/monaco/src/vs/workbench/services/files/node/watcher/win32/csharpWatcherService.ts
[11:23:59] [check semantics] /Users/bpasero/Development/monaco/src/vs/workbench/services/files/node/watcher/typings/chokidar.d.ts
[11:23:59] [check semantics] /Users/bpasero/Development/monaco/src/vs/workbench/services/files/node/watcher/unix/watcherService.ts
[11:23:59] [check semantics] /Users/bpasero/Development/monaco/src/vs/workbench/services/files/node/watcher/unix/watcherApp.ts
Please tag the new version 4.0.5 in this github repository, which is essential for packing this module to debian....
TypeScript 2.4.1 breaks building vscode using tsb: microsoft/TypeScript#16772
I believe we need to port the ts-loader fix from https://github.com/TypeStrong/ts-loader/pull/566/files
I use tsb in the gulpfile of https://github.com/Microsoft/vscode-json-languageservice and observe that the generated source mapping files all source references that are relative to the tsb folder, not to my source folder.
I think the reason is on https://github.com/jrieken/gulp-tsb/blob/master/src/index.ts#L46 where the base path for the tsconfig file is set to __dirname.
The doc says:
basePath A root directory to resolve relative path entries in the config.
Given that paths in tsconfigs are typically relative to the location of the tsconfig file this should be set to that.
For the case where tsconfig is passed in as an object, I suggest to use the current working dir.
For example:
const cjs = tsb.create({
outDir: 'lib',
module: 'commonjs',
target: 'es5',
declaration: true,
lib: ['es5', 'es2015', 'dom'],
sourcemap: true,
experimentalDecorators: true
});
gulp-tsb reports no error, even though the sourceMap
option has a capitalization error.
var tsb = require('gulp-tsb');
var config = {
target: 'es5',
module: 'commonjs',
declaration: false
};
var compilation1 = tsb.create(config);
var compilation2 = tsb.create(config);
// use compilation2
I noticed compilation2
will suddenly create a .d.ts
file for each .ts
file I have, which is a bit annoying.
I should be able to reuse the config
object.
It appears that createCompilerOptions in builder.js should map the client specified JSX value to the integer value typescriptServices.js requires.
None == 0,
Preserve == 1,
React == 2
I've notice that gulp-tsb forces declarations
compiler options to be true
. (https://github.com/jrieken/gulp-tsb/blob/master/src/builder.ts#L68-L69)
Unfortunately, this causes a lot of errors in my app, like:
Parameter 'xxx' of public method from exported class has or is using private name 'xxx'.
Type parameter 'xxx' of exported function has or is using private name 'xxx'.
Since I don't need declarations in my project, I'm fine with them.
But fixing them all in order to migrate to gulp-tsb would be a drag.
Unless it's necessary for some internal workings, please consider not setting declarations
to true
.
First: great project! I've learned a lot just briefly reading through the sources. I plan on spending more time understanding this. Thank you very much.
One thing I've not figured out how to do yet is generate sourcemaps. I think I've tried both the gulp-sourcemap approach and the compiler option, but my target's lib directory still doesn't have any. Can you have a look at these portions of my gulpfile and tell me what I might be doing wrong.
const gulp = require('gulp');
const sourcemaps = require('gulp-sourcemaps');
const tsb = require('gulp-tsb');
const srcFiles = ['src/**/*.ts'];
const cjs = tsb.create({
outDir: 'lib',
module: 'commonjs',
target: 'es5',
declaration: true,
lib: ['es5', 'es2015', 'dom'],
sourcemaps: true, // Complier option
experimentalDecorators: true
});
// Build tasks - TypeScript
gulp.task('build.cjs', function () {
return gulp.src(srcFiles)
.pipe(sourcemaps.init())
.pipe(cjs())
.pipe(sourcemaps.write('.')) // gulp-sourcemaps, intent is to write map in same dir as .js file
.pipe(gulp.dest('lib'));
});
When I provide a "lib" field in tsconfig.json, it works as long as the OS uses slashes (/) as separator for paths. Typescript uses the LanguageServiceHost.getDefaultLibFileName
as a way to get the location of the lib
directory. On Windows the path will contain backslashes () . Typescript uses slashes internally and when it tries to get the directory from a path, it uses slash to find the last path component and failing to return the correct path.
Line 561 in 114c0da
Typescript uses the getDefaultLibFileName
as a backup, if getDefaultLibLocation
is not available on the LanguageServiceHost
. However, when Typescript gets the LanguageServiceHost
from gulp-tsb, it wraps the object in a sort of proxy, which is missing the getDefaultLibLocation
forward.
So a solution would be either:
getDefaultLibFileName
to always return a path with slashes.getDefaultLibLocation
in Typescript and implement the getDefaultLibLocation
in gulp-tsb as well, using (or not) platform dependent separators.I think number 1 should be the easiest and would also follow Typescript's way of using slashes on all platforms.
it start with the folder that you have opened last (like,
~/dev/vscode
) which is never a good choice because why would I open the folder which I opened last again? Instead it should open the folder from which I have opened the last folder (the parent of the current folder,~/dev/
)
Starting 1.8.2 I am getting an issue when running the compile task for vscode-docs.
The issue I am getting:
[13:37:53] Using gulpfile c:\src\vscode-docs\gulpfile.js
[13:37:53] Starting 'build-website'...
[13:37:53] Starting 'compile'...
c:\src\vscode-docs\node_modules\gulp-tsb\node_modules\typescript\lib\typescript.
js:1302
return path.replace(/\\/g, "/");
After debugging this it seems to be a result of b468f60, Typescript does not expect passing an empty string to processRootFile which breaking hell loose.
gulp-tsb currently has typescript
as a dependency. This should be changed to a peerDependency. This avoids that 'hosts' of gulp-tsb
end up having multiple and different versions of typescript installed in their setup.
See also tslint as an example https://github.com/palantir/tslint/blob/master/package.json#L42.
See also microsoft/vscode#2098 that initiated this.
I would like my gulp task to fail if there were TypeScript compilation errors. I couldn't find a way to do this. If it's not already supported, could you consider adding an option for it?
Does master (or other branches) already support the typescript@next
branch of TS? I'm testing it and I'd like to compile with new TS@next options like lib
with gulp-tsb.
Repo
In VS Code, try changing our src/tsconfig
to use "moduleResolution": "node"
:
{
"compilerOptions": {
"module": "amd",
"moduleResolution": "node",
"noImplicitAny": false,
"removeComments": false,
"preserveConstEnums": true,
"target": "es5",
"sourceMap": false,
"experimentalDecorators": true,
"declaration": true,
"noImplicitReturns": true,
"noUnusedLocals": true,
"noImplicitThis": true,
"alwaysStrict": true,
"baseUrl": ".",
"outDir": "../out",
"typeRoots": [
"typings"
]
}
}
Run build script using tsb
Bug
vs/*
modules not resolved. I believe this is because the "baseUrl"
option is either not respected or being set incorrectly.
If you run tsc -p tsconfig.json
, the modules are properly resolved.
Moving from "moduleResolution": "node"
to "moduleResolution": "classic"
would let us consume @types
packages normally instead of maintaining our own copies of them
This might not be a bug, but I couldn't find any option to use the bundled (npm) version of the typescript compiler. it looks like it is using the typescript compiler from the path.
Checkout microsoft/vscode@51108dd
gulp watch-extension:json-client
Works on Linux and & Mac, fails on Windows:
Error: D:/work/3/s/extensions/json/client/src/jsonMain.ts(85,13): Cannot find name 'Promise'.
This plugin looks to be a duplicate of gulp-typescript. Because of that it has been blacklisted (gulpjs/plugins#187). Can you instead of creating your own version consolidate your work into gulp-typescript?
A difference I could find between gulp-typescript & gulp-tsb is that gulp-tsb will recompile only changed files. That can be dangerous as you can see in microsoft/TypeScript#3113. That's why it is not supported in gulp-typescript. If there are more features not supported by gulp-typescript, let me know, so that we can take a look at how these can be implemented in gulp-typescript.
Typescript 1.8 support --allowJs
, but gulp-tsb seems to ignore it.
var tsb = require('gulp-tsb');
// create and keep compiler
var compilation = tsb.create({
target: 'es5',
module: 'commonjs',
declaration: false,
allowJs: true
});
gulp.task('build', function() {
return gulp.src(['src/**/*.ts', 'src/**/*.js'])
.pipe(compilation()) // <- new compilation
.pipe(gulp.dest('dist/'));
});
Correct output files are still generated for respective source *.ts
, but none is generated for the *.js
files.
It works correctly when running tsc
on the command line.
With TypeScript 1.8.2 I'm using tsb with typings.
Typings looks like this -
- typings
|-- browser
|-- ambient
|-- # typings.d.ts
|-- main
|-- ambient
|-- # typings.d.ts
and when I run the gulp task it finds the duplicates in both directories. I'm trying to figure out how to exclude one or the other somehow without success yet, not sure if there is a configuration option for this or not with tsb or if it is a typescript compiler option. The process completes just get a ton of warnings.
Since gulp-tsb removes the outDir compiler at
Line 61 in 35f134a
[error] Cannot write file '/Users/zenorbi/Desktop/test/src/test.js' because it would overwrite input file.
Adding a tsconfig.json file will help organize projects that contain both TypeScript and JavaScript files. Learn more at https://aka.ms/tsconfig.
TypeScript checks for this at https://github.com/Microsoft/TypeScript/blob/b1878e62bfeea57a926185e87449d89f34ba5742/src/compiler/program.ts#L2618 and can be suppressed by adding
options.suppressOutputPathCheck = true;
before
Line 65 in 35f134a
However this would use internal TypeScript options. Would you accept a PR for this?
For example, suppose I give App.ts
as input to gulp-tsb:
// App.tsx
import Helper = require('./Helper');
Helper.doSomething()
On the initial build, gulp-tsb will not fully process Helper.ts
. It will fully process it when you do an incremental build. This leads to the following symptom. If Helper.ts
contains a type error, the initial build won't report it. You'll see it when you do an incremental build.
This is inconsistent with how the TypeScript compiler behaves (e.g. tsc --watch App.ts
). By default it finds, compiles, and type checks imported files. You can disable this behavior with the --noResolve
flag in which case it'll generate an error if you fail to include an imported file as input.
I propose that gulp-tsb's default behavior be to fully process all files it finds through imports during the initial build.
In this case tsb.create(path) returns a nop compilation function that returns null.
Hi, have you tried running this with typescript 2.0 yet?
I have just tried but note I am a novice with typescript at the moment (I'm probably doing something wrong). I received the following error:
D:\Repos\periodic\node_modules\gulp-tsb\lib\builder.js:227
if (!isExternalModule(service.getSourceFile(fileName_1))) {
^
TypeError: service.getSourceFile is not a function
at workOnNext (D:\Repos\periodic\node_modules\gulp-tsb\lib\builder.js:227:55)
at nextTickCallbackWith0Args (node.js:453:9)
at process._tickCallback (node.js:382:13)
Hi guys,
I am trying to use iterators with Map instance and I stumbled upon the issue
Code:
var myMap = new Map();
myMap.set(0, "zero");
myMap.set(1, "one");
for (var [key, value] of myMap) {
console.log(key + " = " + value);
}
transpiles into:
var myMap = new Map();
myMap.set(0, "zero");
myMap.set(1, "one");
for (var _i = 0, myMap_1 = myMap; _i < myMap_1.length; _i++) {
var _a = myMap_1[_i], key = _a[0], value = _a[1];
console.log(key + " = " + value);
}
but Map does not have length
property, intead it has size
I'm working on a fairly large project and we want to use this gulp plugin because the other one is far too slow. However, it looks like even with the --allowJs flag on the compiler, js files are ignored. I've been digging through this for a while now, and changed builder.getScriptFileNames()
to accept js files:
getScriptFileNames(): string[] {
const result: string[] = [];
const defaultLibFileName = this.getDefaultLibFileName(this.getCompilationSettings());
for (let fileName in this._snapshots) {
if (/\.tsx?/i.test(path.extname(fileName))
|| /\.jsx?/i.test(path.extname(fileName))
&& fileName !== defaultLibFileName) {
// only ts-files and not lib.d.ts-like files
result.push(fileName)
}
}
return result;
}
but now I get really strange errors by the typescript compiler:
.../project/node_modules/typescript/lib/typescript.js:48272
throw new Error("Could not find file: '" + fileName + "'.");
even though that file is there (it only does this for js files). I feel like I'm in a little over my head, so I was wondering if anyone here has any idea what's going on?
gulp build
[06:32:22] Local gulp not found in /<<PKGBUILDDIR>>
[06:32:22] Try running: npm install gulp
[06:32:22] Using globally installed gulp
"No inputs were found in config file 'tsconfig.json'. Specified 'include' paths were '[\"src\"]' and 'exclude' paths were '[\"lib/\"]'."
[06:32:22] Using gulpfile /<<PKGBUILDDIR>>/gulpfile.js
[06:32:22] Starting 'build'...
[06:32:22] Starting 'pre-build'...
[06:32:22] Finished 'pre-build' after 8.19 ms
[06:32:22] Starting 'buildWithPreBuild'...
[06:32:22] 'buildWithPreBuild' errored after 967 μs
[06:32:22] Error: Cannot find module './lib-prebuild'
Require stack:
- /<<PKGBUILDDIR>>/gulpfile.js
- /usr/share/nodejs/gulp-cli/lib/versioned/^4.0.0/index.js
- /usr/share/nodejs/gulp-cli/index.js
- /usr/share/nodejs/gulp/bin/gulp.js
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:815:15)
at Function.resolve (internal/modules/cjs/helpers.js:80:19)
at reload (/<<PKGBUILDDIR>>/gulpfile.js:62:22)
at buildWithPreBuild (/<<PKGBUILDDIR>>/gulpfile.js:28:15)
at bound (domain.js:427:14)
at runBound (domain.js:440:12)
at asyncRunner (/usr/share/nodejs/gulp/node_modules/async-done/index.js:55:18)
at processTicksAndRejections (internal/process/task_queues.js:79:11)
[06:32:22] 'build' errored after 11 ms
I nuked my node_modules
folder and re installed to get gulp-tsb
version 1.10.2. I see the same issue that #33 was supposed to fix.
This is what lib/index.js
looks like in my node_modules
folder.
function create(configOrName, verbose, json, onError) {
var config;
if (typeof configOrName === 'string') {
var parsed = typescript_1.readConfigFile(configOrName, function (path) { return fs_1.readFileSync(path, undefined); });
if (parsed.error) {
console.error(parsed.error);
return function () { return null; };
}
config = parsed.config.compilerOptions;
}
Changing undefined
to 'utf-8'
solves the breaking error. Here is the error message I was seeing.
[09:40:07] TypeError: Cannot read property 'on' of null
at DestroyableTransform.Readable.pipe (/Users/waander/Development/Microsoft/vscode-docs/out/vscode-website/node_modules/gulp/node_modules/vinyl-fs/node_modules/through2/node_modules/readable-stream/lib/_stream_readable.js:516:7)
at Gulp.<anonymous> (/Users/waander/Development/Microsoft/vscode-docs/out/vscode-website/gulpfile.js:110:10)
at module.exports (/Users/waander/Development/Microsoft/vscode-docs/out/vscode-website/node_modules/gulp/node_modules/orchestrator/lib/runTask.js:34:7)
at Gulp.Orchestrator._runTask (/Users/waander/Development/Microsoft/vscode-docs/out/vscode-website/node_modules/gulp/node_modules/orchestrator/index.js:273:3)
at Gulp.Orchestrator._runStep (/Users/waander/Development/Microsoft/vscode-docs/out/vscode-website/node_modules/gulp/node_modules/orchestrator/index.js:214:10)
at Gulp.Orchestrator.start (/Users/waander/Development/Microsoft/vscode-docs/out/vscode-website/node_modules/gulp/node_modules/orchestrator/index.js:134:8)
at /usr/local/lib/node_modules/gulp/bin/gulp.js:129:20
at nextTickCallbackWith0Args (node.js:419:9)
at process._tickCallback (node.js:348:13)
at Function.Module.runMain (module.js:444:11)
I would like to use this module, but without Gulp. Would it be possible to do so?
I am using TSC but want to speed it up. tsc -w is pretty fast, but the problem is I cannot hook into it to see when it's done.
So I have tried creating my own tsc compiler watcher that I can control:
microsoft/TypeScript#13608
microsoft/TypeScript#14722
But I am having problems. I could just steal your code, but don't want to use Gulp if I don't have to. Maybe you could modularize it and decouple the transpilation code from the Gulp code. Please lmk, thanks!
Hi there,
Why the version tagged in upstream not matches with npmjs version? 💭
npm version => 4.0.5
github tagged latest version => 2.0.7
Install a workspace from the following zip file:
types.zip
Observe: the compile fails
P:\mseng\VSCode\Playgrounds\bugs\types>gulp build
[14:33:15] Using gulpfile P:\mseng\VSCode\Playgrounds\bugs\types\gulpfile.js
[14:33:15] Starting 'build'...
"P:/mseng/VSCode/Playgrounds/bugs/types/src/test.ts(1,21): Cannot find module 'fs'."
[14:33:16] Finished 'build' after 491 ms
Open the workspace in VS Code and open test.ts. Observe: file has no compile errors.
Commit #33 fixed the problem where readFileSync returns a buffer instead of a string. This was due to not specifying the encoding option.
Although, the source file was fixed, the transpiled file in lib was not checked in.
The latest gulp-tsb npm continues to not specify the encoding option.
BTW: Why are the transpiled files in lib checked in? They should be .gitignored.
The latest PR already fixed what I'm after but there's not been a release since. Any chance of a published release?
The issue I'm facing is as follows:
[13:06:12] Error: Received a non-Vinyl object in `dest()`
at DestroyableTransform.normalize [as _transform] (C:\Documents\Repos\oi\siopa-package-tools\node_modules\vinyl-fs\lib\dest\prepare.js:16:17)
at DestroyableTransform.Transform._read (C:\Documents\Repos\oi\siopa-package-tools\node_modules\readable-stream\lib\_stream_transform.js:182:10)
at DestroyableTransform.Transform._write (C:\Documents\Repos\oi\siopa-package-tools\node_modules\readable-stream\lib\_stream_transform.js:170:83)
at doWrite (C:\Documents\Repos\oi\siopa-package-tools\node_modules\readable-stream\lib\_stream_writable.js:406:64)
at writeOrBuffer (C:\Documents\Repos\oi\siopa-package-tools\node_modules\readable-stream\lib\_stream_writable.js:395:5)
at DestroyableTransform.Writable.write (C:\Documents\Repos\oi\siopa-package-tools\node_modules\readable-stream\lib\_stream_writable.js:322:11)
at Pumpify.Duplexify._write (C:\Documents\Repos\oi\siopa-package-tools\node_modules\duplexify\index.js:212:22)
at doWrite (C:\Documents\Repos\oi\siopa-package-tools\node_modules\readable-stream\lib\_stream_writable.js:406:64)
at writeOrBuffer (C:\Documents\Repos\oi\siopa-package-tools\node_modules\readable-stream\lib\_stream_writable.js:395:5)
at Pumpify.Writable.write (C:\Documents\Repos\oi\siopa-package-tools\node_modules\readable-stream\lib\_stream_writable.js:322:11)
[13:06:12] 'buildTsEs2015' errored after 1.62 s
Hi,
Not really investigated this but I'm running into an issue when using gulp 4.0 and I think it's due to the following (from gulpjs/vinyl-fs):
yes, it was intentional because those versions are missing critical parts to the ecosystem. Vinyl 0.5.3 came with gulp-util, so that's what most people would be using. I might have been able to slip a 0.4.6 -> 0.5.3 change into vinyl-source-stream but I want people to upgrade to 2.0.0 so I don't really care to do that now.
I've not looked into this in any detail. Could the dependency be updated to at least 0.5.3?
gulp-tsb matched my require to the wrong file. I had an import:
import Localizer = require('localizer');
gulp-tsb matched this to a file in the same directory, Localizer.ts
, instead of to the localizer
library which is in the node_modules folder.
I debugged it and identified this logic as being problematic.
Is there a reason that logic was written instead of calling ts.resolveModuleName
? Maybe ts.resolveModuleName
didn't exist when gulp-tsb was written (microsoft/TypeScript#1793)?
Hi,
the last published tag here is 2.0.6. Could you update them ?
Cheers,
Yadd
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.