PSA: moved into babel/babel as @babel/parser -->
Home Page: https://github.com/babel/babel/tree/master/packages/babel-parser
License: MIT License
@babel/parser.The move makes it much easier to release and develop in sync with the rest of Babel!
This repo will be made read-only, as all of the issues/labels have been moved over as well. Please report any bugs and open pull requests over on the main mono-repo.
![greenkeeper[bot] avatar](https://avatars.githubusercontent.com/in/505?v=4 "greenkeeper[bot]")
As of a recent release (Don't know when, exactly, but this issue broke code that was working fine around June 4), babylon's parsing of arrow functions has broken in a very peculiar way. When babylon encounters the following pattern:
<some expression> :
<a parenthesized arrow expression> ?
<an unparenthesized arrow expression>
It reports an error parsing the parenthesized arrow expression:
Module build failed: SyntaxError: <path to file>: Assigning to rvalue (23:3)
For example:
let x = foo() ?
(value => true) :
value => false
The contents of the condition don't seem to matter, nor does parenthesizing the entire conditional expression. However, if the parenthesis around the first arrow function are removed, or parenthesis are added to the second arrow function, or either arrow function is something other than an arrow function, it is parsed fine. This specific pattern is the only one that triggers the error.
For what it's worth, I'm running babylon via babel via webpack, but the stack trace I get is entirely from babylon.
This seems implausible, I know, so I've created a git repo which reproduces the error, available here:
https://github.com/Lucretiel/babylon-error
The specific file I'm trying to pack is index.js with no dependencies or requires. The raw output from webpack is in build_result.
Friday night I'm going nowhere
All the lights are changing green to red
Turning over TV stations
Situations running through my head
Looking back through time
You know it's clear that I've been blind, I've been a fool
To open up my heart to all that jealousy,
That bitterness, that ridicule
Saturday I'm running wild
And all the lights are changing red to green
Moving through the crowds I'm pushing
Chemicals are rushing in my bloodstream
Only wish that you were here
You know I'm seeing it so clear
I've been afraid
To show you how I really feel
Admit to some of those bad mistakes I've made
And if you want it
Come and get it
Crying out loud
The love that I was
Giving you was
Never in doubt
Let go your heart
Let go your head
And feel it now
Let go your heart
Let go your head
And feel it now
Babylon, Babylon, Babylon
Sunday all the lights of London shining,
Sky is fading red to blue
Kicking through the autumn leaves
And wondering where it is you might be going to
Turning back for home
You know I'm feeling so alone
I can't believe
Climbing on the stair
I turn around to see you smiling there
In front of me
And if you want it
Come and get it
Crying out loud
The love that I was
Giving you was
Never in doubt
Let go your heart
Let go your head
And feel it now
Let go your heart
Let go your head
And feel it now
Let go your heart
Let go your head
And feel it now
Let go your heart
Let go your head
And feel it now
Babylon, Babylon, Babylon, Babylon
Make sure to CAPO 1ST FRET
intro:
(D) (D) (A) (A)
e|--2---2-----------2-------2--------------------------------------
B|--3---3---------------3----------2----2------------2------3----
G|--2---2---0h2------------------2----2----------------2--------
D|-----------------------------------2----2----0h2----------------
A|---------------------------------------------------------------------
E|---------------------------------------------------------------------
(Em) (Em)
e|----------------------------------------------------------------------
B|-------------------------------------------------0-------------------
G|------------------------------------------------------2--------------
D|---2------2-----------0--------------------0------------0---------
A|---2------2-----0h2-----2--0---------2--------------------------
E|-----------------------------------2--0------------------------------
Verse:
e|----------------------------------------------------------------
B|-------2h3p2------------3--0--3--3-----------------------
G|-------2-------------------2---------2-----------------------
D|-------------------0------------------------------------------
A|----------------------------------------------------------------
E|---2-------------------3---------------------------------------
Chorus:
The chorus is different in that it doesn't have any individual picking, rather, a soft
strum of these chords:
D, A, Em, A (progression 1)
D, A, Em, G (progression 2)
Progression 2 follows number 1 and continues in this patter until returning to the verse.
Babylon currently will parse multiple exports of the same name, though this should actually be a syntax error.
Here's the relevant portion of the spec and related Babel issue.
I'd love to take a look at and work on this! I currently have an open PR to the main Babel repo (where it was suggested that this change probably belongs in Babylon) with the modified tests. If/once this proposed change lands, I can update that PR to bump the Babylon version and fix the tests accordingly.
I wonder if such syntax should be supported by babylon. For me such a construction makes sense.
*chooseShowResultsInstantly() {
return true === yield this.choose({choices: [true, false]})
}With the latest [email protected] I am unable to decorate generator functions, i.e.
class Foo
{
@deco
* gen() {}
}
will result in an unexpected error.
Here, it will fail if isGenerator is true.
I am currently working on a patch for this and will report back.
RATIONALE
According to 14.3/14.4 of the ECMAScript specification, a GeneratorMethod (14.4) is a valid MethodDefinition (14.3). And in the decorator specification also states that it can be used with a MethodDefinition and makes no limitations whatsoever.
The package reference to core-js is invalid .
$ npm install babylon --save-dev
npm ERR! Windows_NT 6.1.7601
npm ERR! argv "C:\Program Files\nodejs\node.exe" "C:\Users\Gabi\AppData\Roaming\npm\node_modules\npm\bin\npm-cli.js" "install" "babylon" "--save-dev"
npm ERR! node v6.2.0
npm ERR! npm v3.8.8
npm ERR! No compatible version found: core-js@^2.4.0
npm ERR! Valid install targets:
npm ERR! 2.3.0, 2.2.2, 2.2.1, 2.2.0, 2.1.5, 2.1.4, 2.1.3, 2.1.2, 2.1.1, 2.1.0, 2.0.3, 2.0.2, 2.0.1, 2.0.0, 2.0.0-beta.2, 2.0.0-beta, 2.0.0-alpha, 1.2.6, 1.2.5, 1.2.4, 1.2.3, 1.2.2, 1.2.1, 1.2.0, 1.1.4, 1.1.3, 1.1.2, 1.1.1, 1.1.0, 1.0.1, 1.0.0, 0.9.18, 0.9.17, 0.9.16, 0.9.15, 0.9.14, 0.9.13, 0.9.12, 0.9.11, 0.9.10, 0.9.9, 0.9.8, 0.9.7, 0.9.6, 0.9.5, 0.9.4, 0.9.3, 0.9.2, 0.9.1, 0.9.0, 0.8.4, 0.8.3, 0.8.2, 0.8.1, 0.8.0, 0.7.2, 0.7.1, 0.7.0, 0.6.1, 0.6.0, 0.5.4, 0.5.3, 0.5.2, 0.5.1, 0.5.0, 0.4.10, 0.4.9, 0.4.8, 0.4.7, 0.4.6, 0.4.5, 0.4.4, 0.4.3, 0.4.2, 0.4.1, 0.4.0, 0.3.3, 0.3.2, 0.3.1, 0.3.0, 0.2.5, 0.2.4, 0.2.3, 0.2.2, 0.2.1, 0.2.0, 0.1.5, 0.1.4, 0.1.3, 0.1.2, 0.1.1, 0.0.9, 0.0.8, 0.0.7, 0.0.5, 0.0.4, 0.0.3
npm ERR!
npm ERR!
npm ERR! If you need help, you may report this error at:
npm ERR! https://github.com/npm/npm/issues
npm ERR! Please include the following file with any support re
I am building a React project with webpack and noticed that after updating from 6.8.2 to 6.8.3 that setting a checkbox input's checked attribute from whatever is was before to null does not result in the checkbox unchecked. It seems that if it started checked, it will stay checked when set to null, but if it started null, it will appear unchecked until it is clicked.
I expected that setting an attribute to null would be the equivalent of removing that attribute. Is that not the case?
Also, it may be possible that this change was caused by something other than babylon updating, but not as far as I can tell.
Example of the React snippet I am referring to:
<input type="checkbox" checked={condition ? "checked" : null} />
const find = <X> (f, xs) => (true)
<X> should be included in the range of the arrow function like it is in flow
babylon:
"start": 17,
"end": 34,
flow:
"start": 13,
"end": 34,
I started using Flow recently, and was delighted to see that Babel (which I was already using) supported stripping Flow types by default already! I just found a funny issue though:
sebmck: It's being parsed as a JSX tag for some reason.
sebmck: Figured it out exprAllowed is being set to true on delete tokens so the < is being interpreted as the start of a JSX starting tag expression.
thejameskyle: @sebmck is this an easy one to tackle?
class Foo {
delete<T>(item: T): T {
return item;
}
}
copied from https://phabricator.babeljs.io/T1737
Reported by @spudly
const testFunc = async (arg: string = '') => {};
export default testFunc;The code above results in an Unexpected Token error.
If you remove 'async' or remove " = ''", it parses successfully.
Comment by @BLamy
This issue has nothing to do with flow. It's a combination of arrow functions, async-await and destructured default parameters.
const example5 = async function({bar = "bar"}) { // Works fine
console.log(bar);
}
const example6 = async ({bar = "bar"}) => { // Syntax error
console.log(bar);
}
declare class A extends C.B { }
Unexpected token (1:25)
Sorry for using this issue for asking questions.
But I don't understand how to parse JSX with attributes.
I wanted to write a babel plugin to transform JSX code.
I can get an AST with the following code:
var babylon = require('babylon');
var code = '\
<Outer>\
<Inter />\
</Outer>\
';
var ast = babylon.parse(code, {
sourceType: 'module',
plugins: ['jsx']
});
However, an error occurs with the following code:
var code = '\
<Outer>\
<Inter value=0 />\
</Outer>\
';
The error is:
SyntaxError: JSX value should be either an expression or a quoted JSX text
Any suggestions?
((...[, y, z]) => console.log(y, z))(1, 2, 3);However, this code is valid in ES2016. It even works in Chrome 50.
For more information, see https://esdiscuss.org/topic/ignoring-arguments
Reported by @juandopazo
When using async as a parameter name, we get an "Unexpected token" error.
const test = ({async = true}) => {
console.log(async);
};For the case like
({true: 1})token for the key, will look like this -
{
"type": {
"label": "true",
"keyword": "true",
"beforeExpr": false,
"startsExpr": true,
"rightAssociative": false,
"isLoop": false,
"isAssign": false,
"prefix": false,
"postfix": false,
"binop": null,
"updateContext": null
},
"value": "true"
}I believe "keyword": "true" bit should look like this - "keyword": undefined or "keyword": false
Reported by @virtyaluk
Continuing to exploring sources of babylon I've found another interesting moment out of the code.
Look at this and this lines of code:
this.inMethod = this.inFunction = this.inGenerator = this.inAsync = false;and
inMethod: boolean;inMethod is boolean, right?
But in this place the property compared as string:
if (this.match(tt.parenL) && this.state.inMethod !== "constructor" && !this.options.allowSuperOutsideMethod) {There's no assigning string to the property in the whole project. So, I believe, there's no need to performing this check.
See example -
var code = `
var multilinestring = "x\n\
#";
`
try {
require("babylon").parse(code, { sourceType: "module" });
} catch (e) {
console.log(e); // Error!
}I noticed that when I have decorated classes, a decorator closed with a semi-colon is a syntax error, while a semi-colon closing a method in a class is acceptable. Here is my .babelrc:
{
"presets": [
"es2015",
"es2016",
"es2017,
"stage-2"
],
"plugins": [
"transform-decorators-legacy",
"transform-class-properties",
"transform-es2015-block-scoping",
[
"transform-es2015-classes",
{
"loose": true
}
],
"transform-proto-to-assign"
]
}
and an example of the issue to which I am referring:
@decorator('foo') // Semi-colon here throws a syntax error on compile
class Bar {
@decorator('baz'); // Semi-colon here compiles properly
qux() {}
@decorator('baz'); // Semi-colon here compiles properly
static quux() {}
}
Admittedly, I do not know enough about the class/property decorators proposal to determine whether or not this is the expected behavior or this is some inconsistency with the AST parser or the babel-plugin-transform-decorators-legacy plugin specifically. @loganfsmyth recommended I open an issue here.
I tried using Babylon parser as a replacement for Esprima, discovering that the AST it produces doesn't quite correspond to the ESTree spec. Which is even more surprising because the README states that Babylon is based on acorn, which does conform to ESTree spec.
I found no documentation about this. So far I've discovered the following differences:
I'd like to evaluate whether it's feasible for me to switch the parser to Babylon... but I'm not really sure how big the AST differences turn out to be.
reported by imaxmaxmaximus in phabricator
The parse interprets this
class Cat {
symbol = 10
[symbol] = 10
}as
class Cat {
symbol = 10[symbol] = 10
}With semicolon there is a parsing error:
class Cat {
symbol = 10;
[symbol] = 10;
}With the flow plugin, #19 seems to have regressed parsing performance on really giant files.
Before #19 (e6c11a0), this finished in about 0.5 seconds. After, it takes hours:
curl -O https://raw.githubusercontent.com/mbostock/topojson/master/examples/world-50m.json
node -e 'require("/path/to/babylon").parse("(" + require("fs").readFileSync("world-50m.js", "utf-8") + ")", { plugins: [ "flow" ] })
There is no problem if the flow plugin is disabled. It looks like the this.state.clone() calls get slower and slower as it parses more of the file. Maybe the total runtime is O(n^3) in the size of the file? That would put us at about 470 hours to parse the file based on a bit of logging I did.
This is blocking me from updating us to use a newer Babylon. (Actually, the reason I want to upgrade is to get the fix from #19…)
let foo = <bar x={function(x): Array<string> {}} />;
fails to parse (as of babylon-6.7.0: astexplorer), saying the / is unexpected.
wrapping Array<string> in parens parses correctly.
Trying to parse ((-1) ** 2); fails with the following error, despite already being wrapped in parens:
Illegal expression. Wrap left hand side or entire exponentiation in parentheses. (1:3)
> 1 | ((-1) ** 2);
| ^
I found that write jsx elements directly after yield statement would cause a syntax error (Unexpected token). But according to jsx spec (https://facebook.github.io/jsx/) and ECMAScript spec. JSXElement is a PrimaryExpression which can be used after yield statement.
Currently Error but should be OK:
yield <a></a>;
Currently OK:
yield (<a></a>);
Because I am writing a program heavily depends on generator functions. I want my code be more clear. So I forked this project and fix this problem in commit de56e12. There is just one line difference where I add { startsExpr: true } to jsxTagStart token.
Because I am not familiar with the internal representation in this project. I don't know if it is proper to do such a change. But at least there is no test failed after change.
in flow 0.28 this new syntax was added, which is not yet supported by babylon:
declare module "foo" { declare export ...; }
This is the relevant flow change, with a lot of examples in the tests.
facebook/flow#1811
Line 36 in 8b15081
Despite binding.referencePaths being replaced with path.replaceWith the resulting code is missing them.
You can see here they are all supposed to be _noop3.default and _range3.default but some are still _noop and _range instead:
myFunc(_range3.default, _noop3.default);
myFunc(_noop, _noop3.default);
myFunc(_range3.default, _noop, _noop3.default);
myFunc(_range, _noop, _range3.default, _noop3.default);
myFunc(_range, _noop, _range, _noop3.default, _range3.default);Related to lodash/babel-plugin-lodash#91.
Issue originally made by @SystemParadox on babel/babel#2387
function test() {
await foo();
}Throws: Unexpected token(2:8)
This is a bit misleading. Can we change this to say something like "await can only be used in async functions"?
Thanks.
Currently declares inside declare module don't need to start with a declare name. For example this is valid code:
declare module A {
placeanythinghere var a:number
}
Flow itself also parses it. I know flow tries not to fail in most situations, but do we also want to do that in babylon?
It could be easily changed and there is already a todo, but I'm not sure what the wanted way currently is.
I believe the Babylon parser is incorrectly including the delimiter in .loc.end.column of ObjectTypePropertys:
var babylon = require('babylon');
var flow = require('flow-parser');
var code = `
type X = {
a: number,
}
`;
var endColumnOfPropertyBabylon =
babylon.parse(code, {plugins: ['flow']})
.program.body[0].right.properties[0].loc.end.column;
var endColumnOfPropertyFlow =
flow.parse(code, {})
.body[0].right.properties[0].loc.end.column;
// outputs "12 11"
console.log(endColumnOfPropertyBabylon, endColumnOfPropertyFlow);
This bug causes recast to insert double delimiters in some cases: benjamn/recast#282
the babylon.js uses console.log(JSON.stringify(ast, null, " ")); to dump the ast output, which will run out of memory if the js file is roughly more than 1M (the AST text becomes close to 1G).
It would be nice to provide an option to babylon.js to strip the tokens from the output, as they take up most of the space and are often useless.
From https://phabricator.babeljs.io/T7378
Example
async function a() {
await
1;
}http://astexplorer.net/#/Wq8Hq7MjF0
or is that correct?
According to the spec when defining multiple variables with the same name, the parser should throw and SyntaxError when using let or const:
let foo, foo;
or
let foo; let foo;
From 13.2.1.1:
It is a Syntax Error if the BoundNames of BindingList contains any duplicate entries.
V8 trows an error for let and const, but not vor var.
let f: * = (x: null | *): (*) => {}
Looks like the parser doesn't expect * outside of type argument brackets. Here are some examples.
copied from https://phabricator.babeljs.io/T7060
Can someone confirm that this is valid flow syntax? @gabelevi maybe
Because it seems to work when doing:
let f: * = (x: null | *): * => {}
Issue originally made by @markelog
Ref babel/babel#3774
require("babylon").parse("2++");Will throw a error -
"SyntaxError: Assigning to rvalue (1:0)"
Which is pretty cryptic, parsers like esprima, or any other JS engine will show more meaningful message - "Invalid left-hand side expression in postfix operation"
export default myplugin = ({ type:t }) => {
let visitor = {
stringLiteral ( path ) {
asyncfn(path, result =>{
// do something async
// how can i get these async result into ast tree?
})
}
}
return {
visitor
}
}Reported by @virtyaluk
I'm exploring source code of babylon parser and saw next code under lval.js:
// Parses spread element.
pp.parseSpread = function (refShorthandDefaultPos) {
let node = this.startNode();
this.next();
node.argument = this.parseMaybeAssign(refShorthandDefaultPos);
return this.finishNode(node, "SpreadElement");
};Pay attention to the line:
node.argument = this.parseMaybeAssign(refShorthandDefaultPos);And have a look at parseMaybessign signature:
function (noIn, refShorthandDefaultPos, afterLeftParse)Seems like argument passed in wrong order.
I believe, there's need to pass some bool argument first and only then pass refShorthandDefaultPos.
Am I wrong?
I propose that support for decorators on computed properties is added to babylon.
It was suggested in babel-eslint repo, that I open an issue here.
Related issue: babel/babel-eslint#309.
This doesn't work right now:
@autobind
[method](arg) {
// do something
}Consider this example -
({ test = 1 } = {})Then relevant parts of generated AST would look like this -
"properties": [
{
"type": "ObjectProperty",
"start": 3,
"end": 11,
"loc": {
"start": {
"line": 1,
"column": 3
},
"end": {
"line": 1,
"column": 11
}
},
"method": false,
"shorthand": true,
"computed": false,
"key": {
"type": "Identifier",
"start": 3,
"end": 7,
"loc": {
"start": {
"line": 1,
"column": 3
},
"end": {
"line": 1,
"column": 7
}
},
"name": "test"
},
"value": {
"type": "AssignmentPattern",
"start": 3,
"end": 11,
"loc": {
"start": {
"line": 1,
"column": 3
},
"end": {
"line": 1,
"column": 11
}
},
"left": {
"type": "Identifier",
"start": 3,
"end": 7,
"loc": {
"start": {
"line": 1,
"column": 3
},
"end": {
"line": 1,
"column": 7
}
},
"name": "test"
}Notice duplication in ObjectProperty for key and in AssignmentPattern for left properties - Identifier node is used twice.
This creates weird issues for traversing and for code generation.
There is a bug in the AST, where in arrows functions, the loc's for params with flow types only cover the argument identifier (or rest element), and not the flow type. @zertosh
Ref babel/eslint-plugin-babel#64, https://github.com/babel/eslint-plugin-babel/pull/64/files#diff-7f0b9d9a07eb0ef5f9145411c7980679R235
{code: 'f = (a:T) => {}', output: 'f = (a:T,) => {}', options: ['always'], errors: MISSING_I},
and it is ok in FunctionDeclaration/FunctionExpression
babylon/src/util/identifier.js
Line 37 in a1f42e7
tools/generate-identifier-regex.js but no such script exists in the repo.
It appears this was copied from https://github.com/ternjs/acorn/blob/3b4ab11ead6eb5fc4f9d2a8ef535d3b2ce699af1/src/identifier.js#L35.
Either way, please include the script.
This parses:
function* foo(z) {
const x = ((yield 3): any)
}
But this does not:
function* foo(z) {
const x = (yield 3: any)
}
The latter is parseable by flow:
Both expressions below produces the same error(using the babel online repl in various settings),
"Illegal expression. Wrap left hand side or entire exponentiation in parentheses."
(-2) ** 2;
((-2) ** 2);
According to this reference it should work,
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Arithmetic_Operators#Exponentiation
Looking briefly at the source,
babylon/src/parser/expression.js
Line 186 in 8b15081
My best guess is that it should also check if "left.extra.paranthesized" is false!
Cheers
Error: 'this' is not allowed before super()
class Class extends null {
constructor(name) {
this.name = name
}
}Babel must not be throw error if we access to this without super() if parent class is null.
Null parent class hasn't constructor, an obvious logical fallacy.
Temporary hack:
class NullClass extends null {
}
class Class extends NullClass {
constructor(name) {
super()
this.name = name
}
}My project's babylon package upgraded to 6.8.0 today as a result of a devDependency of babel-core. As a result, some stuff broke.
Specifically in my app I do some dynamic babel parsing (ala. repl). So I import babel directly like this:
import preset_es2015 from 'babel-preset-es2015';
import preset_react from 'babel-preset-react';
import preset_stage0 from 'babel-preset-stage-0';
import {transform} from 'babel-core';
It seems this no longer works with 6.8.0 and results in the following error stack:
The top-most item in the stack is babylon/lib/index.js failing on var _parser = require("./parser");
Rolling back to [email protected] makes the errors go away.
I looked through the 6.8.0 CHANGELOG for both babylon and babel-core and can't see any reason why this would be happening. Can you please advise?
function g(a:number=1, e=1:number) {}
for a:number=1 the AssignmentPattern loc start and end is 19-21 see here when it should be 11-21?
Reported by @Gozala
While I would expect it to work same as when there is no line break at the end of line 2.
class A {
constructor
( a
, b
) {
}
}
Babylon can't handle the following syntax:
declare module.exports: {}
It was introduced in flow 0.25
Can we export the Parser class from Babylon? We are already very close to doing so on this line.
Then Babel plugins would be able to override Parser methods like getTokenFromCode() to add support for new tokens. For example, adding support for a # token:
import * as babylon from "babylon";
babylon.tokTypes.hash = { label: "#", beforeExpr: true };
let {getTokenFromCode} = babylon.Parser.prototype;
babylon.Parser.prototype.getTokenFromCode = function(code) {
if (code === 35) { // '#'
++this.state.pos;
return this.finishToken(babylon.tokTypes.hash);
}
return getTokenFromCode.bind(this)(code);
};At the very least, it would be nice to have some hooks into the different Parser methods.
Reported by @pavelkornev
Following snippet:
function A({set}) {
set = "a"
}
compiles to:
"use strict";
function A(_ref) {
var set = _ref.set;
set = "foo";
}
But when we try to assign default value to "set":
function A({set="bar"}) {
set="foo"
}
it crashes with the following error:
repl: Unexpected token (1:15)
> 1 | function A({set="bar"}) {
| ^
2 | set="foo"
3 | }
On other hand if we assign alias to it:
function A({set:set_="bar"}) {
set="foo"
}
It compiles just fine:
"use strict";
function A(_ref) {
var _ref$set = _ref.set;
var set_ = _ref$set === undefined ? "bar" : _ref$set;
set = "foo";
}
If "set" reserved why does it work in first case? If it's not why second case doesn't work? I consider this as a bug of compiler, am i right?
React
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
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
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.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.