typings / discussions Goto Github PK
View Code? Open in Web Editor NEWFor discussions and issues with Typings or TypeScript definitions
For discussions and issues with Typings or TypeScript definitions
Hi there,
I was just thinking ... wouldn't it be an idea to typedoc each registered definition, and add that information to the (yet to be completed) registry? That way, developers can quickly look up the type signature of a function, and see which (sometimes hidden) type names are used.
The faq says -
Global dependencies are type definitions that are global or otherwise provide information about the environment. Some examples of "environment" dependencies are Node.js, Browserify, window and even Array.prototype.map. These are globals that exist at runtime, you do not "require" them.
I am using the css module from npm and try to install typings using typings install dt~css
, the logic being that according to the faq, since i need to require (or import) the module in order to use it, then it is not a global.
However i get the error.
Attempted to compile "css" as an external module, but it looks like a global module. You'll need to enable the global option to continue.
This doesn't make any sense to me.
Hello,
I am currently writing a typing for WebdriverIO.
WebdriverIO has two modes, standalone
and wdio
test runner based on mocha
.
In standalone mode client is responsible for initializing and closing browser session and more over in standalone mode API works synchronously.
In wdio mode test runner will initialize and clean up browser
object and API works asynchronously. This browser
object available globally when run via test runner.
I have a working code for the standalone mode. My question is what can be done to make this global browser
object available from typescript library.
I am seeing examples to make global module but not sure whether this is the best way to do it?
Thanks in advance.
Regards,
Farhan
I will clarify my question: Looking through the registry, I could not find typings that did not point to a single version of a given library's typings. Let's take redux-thunk as an example, right now it's pointing to typings for version 1.0.4. When/if redux-thunk releases a version 1.0.5 or 2.0.0, is there plan to simply add this version and keep the old version so it becomes possible to download either versions of the typings, depending on which one is used in a given project?
I feel like that is the plan, but I would like to confirm since that's something that did stop me from using TypeScript in the past, the way DefinitelyTyped handled versioning of typpings and how convoluted that repository became.
I've been working locally with slightly tweaked DT definition files for React and Flux to un-globalize them and would like to add them to the registry. Good information I'm following in the registry README, but didn't quite catch the process to add the typings under the typed-typings namespace.
So I recently started using Typescript and of course I want to use my own packages with it and include the typings files inside the npm package itself.
My npm package is designed where the root entry point points to a "class" that you use new on to create a new instance of said class.
const SmartBuffer = require('smart-buffer');
let buff = new SmartBuffer();
What I struggled with was how to properly write the definitions files for it. Do I need to wrap it in a module? Just export declare a class? Eventually I got it to where I can import with typescript like this:
import SmartBuffer = require('smart-buffer');
let buff = new SmartBuffer();
And vscode/webstorm etc all have intellisense for the instance buff.
I just wanted to make sure this is the proper way to write the definition files in this particular instance:
https://github.com/JoshGlazebrook/smart-buffer
(there is only one .d.ts file so it shouldn't be too much of a pain to look through)
Let's not merge namespace hacks so people can use "ES6-style imports" with CommonJS code. Remember to point out when someone is using an import incorrectly. I'm adding this issue mostly as a bookmark for future reference, since I commonly write something up like typed-typings/npm-basic-auth#1 (comment). There's a good answer on Stack Overflow by Ryan we can point people to now - https://stackoverflow.com/questions/39415661/why-cant-i-import-a-class-or-function-with-import-as-x-from-y 👍
Originally I tend to organize typings in multiple files so that they are more manageable. e.g. npm-chai
.
But now through the conversation in UMD, and best practice of exposing types, it seems like it is actually best to keep them in 1 file (or 2, if we can't nicely solve the UMD issue microsoft/TypeScript#7125 and microsoft/TypeScript#7156)
The key statement is this:
"how would it look like if the package is actually written in TypeScript and compiled using tsc -d
"?
It has the following benefits:
lib
or src
? Nested or mirror source structure?).d.ts
file can easily be moved into the source package when package author agreesRelevant discussions:
typings/typings#402
typings/typings#10
typings/typings#354
I was thinking of creating a website for badges, in the spirit of sites like http://david-dm.com, for providing badges that inform the user whether the package has typings associated with it. This would promote the creation of typings for packages. Sounds like a good idea? If so, I'd be able to work on it this summer holiday.
I have a framework library written in javascript.
https://github.com/webgme/webgme
The documentation looks reasonable.
https://editor.webgme.org/docs/source/PluginBase.html
As a first step in prepaing to use typing, I made a typing project and filled in a few interfaces by hand.
https://github.com/phreed/npm-webgme
I have a project that uses the webgme library.
https://github.com/phreed/webgme-immortals
That is being converted to use TypeScript.
Include the typing descriptions that are in phreed/npm-webgme into phreed/webgme-immortals.
typings install webgme=github:phreed/npm-webgm
How do I configure a project including the type definitions, to be used by a typescript project?
Hi I'd like to colaborate with some typings I'm using and I'd like to understand the best way to do it.
Let's say for instance Immutable-js. The project already have the d.ts file, so I don't have to create it. Should I create a repository on github for the typings.json? Or would it be better to add the file to their repository?
Also, in that case, what's the difference between the main and the browser properties for the typings.json?
Finally, in the example used in the docs for the debug.json version file, there's a hash there, I could no find a commit related to that hash? From where that hash came?
Thanks
It'd be nice to have a typings website that can point people to getting started and searching and reading about how to write typings and use TypeScript.
Some resources:
@blakeembrey the Registry team should not be admin of repositories https://github.com/orgs/typings/teams/registry/repositories, because i'll be able to use dangerous funtions.
I prefer write access.
Can you please explain this a bit more?
For example I run typings search node
and results show me that node available as "env" source.
What does that mean? And how to install node from "env" source?
I've tried typings install env:node
(ha-ha) without success.
I have a handful of type definitions (some converted from DT) that embrace the use of external modules that was a huge selling point when typings got started. I'm starting a new project and this is my first opportunity to get in sync with Typings 2.0's support for installing type definitions. I spent a fair amount of time getting caught up on everything, but everything is still a bit disjointed. I got some questions/musings:
npm install @types/react
, which pulls a migrated definition from the old DefinetlyTyped. With typings, typings/registry
was the preferred repo.
typings/registry
takes precedence over what @types
is using? Especially considering that a handful of PR's to fix/update some definitions only had the registry definitions in mind - not those in DefinetlyTypedtypings/registry
with Typescript 2? Btw, how would I do that now?I'm very patient and excited to see this all become 'standardized' in a way; I have no strong opinions and am along for the ride :) but, it's always been a bit painful. Thanks for any thoughts.
I've published an npm package: angular-cc-appinsights.
The package is targeting front-end angular 1 developers and will therefore be loaded as a script tag from the the locally installed node_modules directory.
The package is written in typescript and compiled to JavaScript with declaration files.
Reading the examples of how to publish my typings, I seem to fall into both example 2 and 5.
I have gone with option 5: include in the npm package the compiled JS and declaration files.
At first blush, this seems to be the right thing to do. Certainly when I go and install my package into an angular application written in typescript the typescript language service picks up my typings from the npm package.
However, I have a nagging feeling I'm not doing things correctly or at least not in keeping with the spirit of the typings project.
My doubts are two fold:
declare module "angular-cc-appinsights" {
import appinsights = cc.appinsights;
export = appinsights;
}
This I believe is a problem as I should somehow be describing which specific version of angular typings I'm depending on
Can you guys point me to the correct approach?
Thanks
Christian
This is more a question about writing type definitions than about typings, feel free to let me know if I should post this elsewhere!
I've been working on the type definitions for Griddle, which only exports a React class, essentially to be used like so:
import * as React from 'react';
import { render } from 'react-dom';
import Griddle from 'griddle-react';
render(
<Griddle />,
document.getElementById('root')
);
There are some interfaces in my definition that would be really great for a developer to be able to consume, but I haven't found a good way to make it available. If I simply export them along side the true default export, they need to access it in a way that doesn't look so great:
import {default as Griddle, CustomColumnComponentProps} from 'griddle-react';
If I was able to declare a namespace that contained the interface that wasn't wrapped by typings in the ambient module declaration, they could gain direct access to the interface. Something resulting like:
declare namespace GriddleReact {
export interface GriddleProps {
someProp: string;
}
}
declare module 'griddle-react' {
export default class Griddle extends React.Component<GriddleReact.GriddleProps, any> {}
}
which could then be used like:
import Griddle from 'griddle-react';
var someProps: GriddleReact.GriddleProps = {someProp: 'prop'};
Is this frowned upon because it pollutes the environment with a namespace that the consumer may not be expecting? Any other thoughts or good ways to do this?
Should be able to write the node typing as a single file with dependencies on the native node modules - relies on typings/typings#1 working.
<purpose>-<name>
env-atom
, env-electron
<most common package manager>-<name>
bower
)npm
is not likely to go away, but others not really sure (e.g. bower
)typed-<name>
typed-
is redundant.<owner>-<name>
atom/electron
to electron/electron
)Should be able to support Express.JS without ambient issues.
This issue is to support/mirror discussion on #5537 but from the typings
side.
While we've not yet nailed down a plan on what out endgame is in the compiler, one thing I know I'd certainly love to see typings
do really well is discovery for a package's type information. We want to see users go from npm install bluebird --save
to actually having the third-party types for that package (of the correct version!) available for them to depend on and use in editor and compilation experiences as seamlessly as possible.
@blakeembrey mentioned a resource for typings
to use to automate discovery of typings, and potentially browse-able by humans. This would be excellent - potentially being able to locate the corresponding types for a series of package.json
entries is a big step towards making finding existing types as seamless as possible. We'd love to know how your design and implementation with this proceed.
Pinging @mhegazy @ahejlsberg @vladima @DanielRosenwasser for their thoughts.
What do you think about letting each developer maintaining there own versions mapping inside their own typings.json (for simplicity purpose) and registry only mapping name => repo only like jspm registry does actually registry.json
{
"name": "electron",
"main": "electron.d.ts",
"author": "koalabz <[email protected]>",
"description": "The TypeScript definition for electron.atom.io",
...
"versions": {
"0.35.4": "#c597a7362eb4605ad737217a19b701d4cf2bc80a",
"0.36.0": "#2689b1648190d6921496a3f94c0d4e1ecae2ef1f"
},
"repository": {
"type": "git",
"url": "https://github.com/koalabz/typed-electron.git"
},
...
}
Pros:
project
=> repos
typings.json
didn't need extra"ambientDependencies": {
"node": "github:DefinitelyTyped/DefinitelyTyped/node/node.d.ts#5cb07b53719466b27cb32f3eb2c7c3e22575ecda"
}
declarations but only the essential like package.json
does
"dependencies": {
"bluebird": "^0.12.0"
}
Hello! I am interested in finding a definition file for firmata.js (or in helping to generate one). The way I'm giving myself typescript support for firmata.js right now is INCREDIBLY HACKY. In fact, I know its the wrong way and I know all it is doing is keeping the compiler from complaining and helping provide me with some auto-completion. So I would really like some help in figuring out the right way to do this. Eventually I'd like to include a typings file in DefinitelyTyped so I can use $ typings search firmata
and $ typings install --save --global dt~firmata
.
What I have so far I use with
import { IBoard } from './interfaces/Firmata';
And the file Firmata.d.ts
has this for its contents
/**
* Created by troy on 9/19/16.
*/
// Most of these are generated by observing https://github.com/firmata/firmata.js/blob/master/lib/firmata.js
// TODO this can definitely be done better with a better understanding of prototypal inheritance
import SerialPort = require("serialport");
export interface IBoard
{
// ==========
// Properties
// ==========
MODES:{
INPUT:number, OUTPUT:number, ANALOG:number, PWM:number, SERVO:number, SHIFT:number, I2C:number, ONEWIRE:number,
STEPPER:number, SERIAL:number, PULLUP:number, IGNORE:number, PING_READ:number, UNKOWN:number
},
I2C_MODES:{ WRITE:number, READ:number, CONTINUOUS_READ:number, STOP_READING:number },
STEPPER:{
TYPE:{ DRIVER:number, TWO_WIRE:number, FOUR_WIRE:number },
RUNSTATE:{ STOP:number, ACCEL:number, DECEL:number, RUN:number },
DIRECTION:{ CCW:number, CW:number }
},
SERIAL_MODES:{ CONTINUOUS_READ:number, STOP_READING:number },
SERIAL_PORT_IDs:{
HW_SERIAL0:number, HW_SERIAL1:number, HW_SERIAL2:number, HW_SERIAL3:number,
SW_SERIAL0:number, SW_SERIAL1:number,SW_SERIAL2:number, SW_SERIAL3:number, DEFAULT:number,
},
SERIAL_PIN_TYPES:{
RES_RX0:number, RES_TX0:number, RES_RX1:number, RES_TX1:number,
RES_RX2:number, RES_TX2:number, RES_RX3:number, RES_TX3:number,
},
HIGH:number,
LOW:number,
pins:[{
mode:number,
value:number,
supportedModes:number[],
analogChannel:number,
state:number
}],
ports:number[],
analogPins:number[],
version:{},
firmware:{
name:string,
version:{
major:number,
minor:number
},
},
currentBuffer:number[],
versionReceived:boolean,
name:string,
settings:IOptions,
// TODO handle this more cleanly, currently a black box
transport:SerialPort,
// ====================
// Constructor Function
// ====================
Board:(port:string|IPort, options?:IOptions, callback?:(err:any)=>void)=>IBoard,
// =================
// Prototype Methods
// =================
reportVersion:()=>void,
queryFirmware:()=>void,
analogRead:()=>void,
analogWrite:()=>void,
pwmWrite:()=>void,
servoConfig:()=>void,
servoWrite:()=>void,
pinMode:(pin:number, mode:number)=>void,
digitalWrite:(pin:number, val:number)=>void,
digitalRead:(pin:number, callback:(val:number)=>void)=>void,
queryCapabilities:()=>void,
// TODO give these better definitions
queryAnalogMapping:()=>void,
queryPinState:()=>void,
sendString:()=>void,
sendI2CConfig:()=>void,
i2cConfig:()=>void,
sendI2CWriteRequest:()=>void,
i2cWrite:()=>void,
i2cWriteReg:()=>void,
sendI2CReadRequest:()=>void,
i2cRead:()=>void,
i2cStop:()=>void,
i2cReadOnce:()=>void,
sendOneWireConfig:()=>void,
sendOneWireSearch:()=>void,
sendOneWireAlarmsSearch:()=>void,
_sendOneWireSearch:()=>void,
sendOneWireRead:()=>void,
sendOneWireReset:()=>void,
sendOneWireWrite:()=>void,
sendOneWireDelay:()=>void,
sendOneWireWriteAndRead:()=>void,
_sendOneWireRequest:()=>void,
setSamplingInterval:(interval:number)=>void,
getSamplingInterval:()=>void,
reportAnalogPin:()=>void,
reportDigitalPin:(pin:number, value:number)=>void,
pingRead:()=>void,
stepperConfig:(deviceNum:number, type:number, stepsPerRev:number, dirOrMotor1Pin:number, stepOrMotor2Pin:number,
motor3Pin?:number, motor4Pin?:number)=>void,
// TODO define callback function better
stepperStep:(deviceNum:number, direction:number, steps:number, speed:number, accel:number, decel:number,
callback:Function)=>void,
serialConfig:()=>void,
serialWrite:()=>void,
serialRead:()=>void,
serialStop:()=>void,
serialClose:()=>void,
serialFlush:()=>void,
serialListen:()=>void,
sysexResponse:()=>void,
sysexCommand:()=>void,
reset:()=>void,
// ==============
// Static Methods (I think)
// ==============
isAcceptablePort:(port:IPort)=>boolean,
requestPort:(callback:(err:any, port:IPort)=>any)=>void,
encode:(data:number[])=>number[],
decode:(data:number[])=>number[],
// TODO define callback function better
// TODO these need to be organized better
on:(event:string, callback:Function)=>void,
emit:(event:string)=>void,
// ======
// Custom (added by Joshua's firmata connector)
// ======
log:(message:any, ... optParams:any[])=>void,
error:(message:any, ... optParams:any[])=>void,
debug:(message:any, ... optParams:any[])=>void,
info:(message:any, ... optParams:any[])=>void,
warn:(message:any, ... optParams:any[])=>void,
}
interface IPort
{
comName:string,
}
interface IOptions
{
reportVersionTimeout?:number,
samplingInterval?:number,
serialPort?:{
baudRate:number,
bufferSize:number,
}
}
As you can see, there are incomplete functions and I'm probably doing this the worst way possible, so any help is greatly appreciated.
E:\YAP>typings install github-electron --save
typings ERR! message Unable to find "github-electron" ("npm") in the registry. Did you want to try searching another source? Also, if you want contribute these typings, please help us: https://github.com/typings/registry
typings ERR! caused by https://api.typings.org/entries/npm/github-electron/versions/latest responded with 404, expected it to equal 200typings ERR! cwd E:\YAP
typings ERR! system Windows_NT 10.0.10586
typings ERR! command "E:\Nodejs\node.exe" "C:\Users\Administrator\AppData\Roaming\npm\node_modules\typings\dist\bin.js" "install" "github-electron" "--save"
typings ERR! node -v v5.10.1
typings ERR! typings -v 1.0.4
In the examples...
https://github.com/typings/typings/blob/master/docs/examples.md
...there does not seem to be one for RequireJS.
Is there an example package that does?
There is an example for CommonJs/NodeJs (3).
Incidentally, this is the substance of what I was trying to convey with #19
Hey all, I'd like to volunteer to help move this project forward.
Please advise on where help is most needed.
Make a "typed typings" organisation to hold all the typings being created "officially".
Could it because the error logging: typings ERR! message ...
and so on are too "formal" and similar to npm error message so that when people see the error, they freak out and think there must be some fatal errors.
Therefore they file issue with the message attached instead of just reading the message and figure out why?
For sure we see this behavior a lot.
Maybe soften up the messages would help?
The Aurelia team has been doing a lot of work to make our d.ts support follow official recommendations. As such, we have a typings field in our package.json file for each library which points to the correct d.ts file. This works fine for users of our cli and webpack, however it doesn't work for jspm users. We know Microsoft has a new solution, but it doesn't seem to be ready so we'd like to support the typings tool for jspm users. We can place typings.json files into our repos, no problem. We've done this with one repo as a test: aurelia-pal. However, when we try to install that using typings, we always get the old version, not our currently released version from npm. I had a look at your registry and it seems that someone has created entries for this already. I'm wondering if that is causing the problem. If we added typings.json files to all our libraries and then removed your registry entries, would typings always grab the latest release from npm? Would that fix our issue?
(Apologies for the double post...I didn't see this repo earlier.)
I'm interested in contributing some typings to an npm package I maintain. I've started writing it and added it to package.json like this
{
"typings": "./my-package.d.ts"
}
In order to test it, I've created a separate consuming app and npm linked my package into it. Is there a way to get typings to use the typings in locally linked packages?
Also, once, I'm happy with my typings, will publishing the package with the typings file to npm be enough to make it available to users in typings by doing a typings install my-package
?
Hello @blakeembrey,
I would like to get typings for the localForage library and use those in my project.
At first, I tried using tsd and thus the following typings file: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/localForage/localForage.d.ts
Unfortunately, it imports the es6-promise typings and because Angular 2 (which I also use in my project) expose that already, I end up with the dreaded duplicate identifier error (on 'Promise'):
$ tsd install localForage
- localForage / localForage
-> es6-promise > es6-promise
>> running install..
>> written 2 files:
- es6-promise/es6-promise.d.ts
- localForage/localForage.d.ts
$ tsc
node_modules/angular2/typings/es6-shim/es6-shim.d.ts(475,11): error TS2300: Duplicate identifier 'Promise'.
node_modules/angular2/typings/es6-shim/es6-shim.d.ts(552,13): error TS2300: Duplicate identifier 'Promise'.
typings/es6-promise/es6-promise.d.ts(11,15): error TS2300: Duplicate identifier 'Promise'.
typings/es6-promise/es6-promise.d.ts(42,16): error TS2300: Duplicate identifier 'Promise'.
Then, since I wanted to give your project a try, I've decided to give it a go, except that I don't really know where to start :)
I first tried a command that failed (can't remember what it was), which led me to fork the registry and try to add a reference towards definitelytyped for localForage: https://github.com/dsebastien/registry-1/commit/828d9998570d4d548f15f9eff9baa8f92e7cc239
Then I found the --ambient
flag and realized that it's probably not worth a pull request (?).
Then I've tried typings install localForage --ambient --save
which did find the typings on DefinitelyTyped and download those:
$ typings install localForage --ambient --save
? Found typings for localForage in DefinitelyTyped. Ok? Yes
Installing localForage@* (DefinitelyTyped)...
References (not installed):
github:DefinitelyTyped/DefinitelyTyped/es6-promise/es6-promise.d.ts#c192586e9e3c5180e271dbd21e7295aaf1dcdbb6 (from localForage)
localForage
└── (No dependencies)
Unfortunately, tsc complains a bit afterwards:
$ tsc
typings/browser/ambient/localForage/localForage.d.ts(10,5): error TS2300: Duplicate identifier 'driver'.
typings/browser/ambient/localForage/localForage.d.ts(12,5): error TS2300: Duplicate identifier 'name'.
typings/browser/ambient/localForage/localForage.d.ts(14,5): error TS2300: Duplicate identifier 'size'.
typings/browser/ambient/localForage/localForage.d.ts(16,5): error TS2300: Duplicate identifier 'storeName'.
typings/browser/ambient/localForage/localForage.d.ts(18,5): error TS2300: Duplicate identifier 'version'.
typings/browser/ambient/localForage/localForage.d.ts(20,5): error TS2300: Duplicate identifier 'description'.
typings/browser/ambient/localForage/localForage.d.ts(24,5): error TS2300: Duplicate identifier '_driver'.
typings/browser/ambient/localForage/localForage.d.ts(28,5): error TS2300: Duplicate identifier '_support'.
typings/browser/ambient/localForage/localForage.d.ts(46,5): error TS2300: Duplicate identifier 'LOCALSTORAGE'.
typings/browser/ambient/localForage/localForage.d.ts(47,5): error TS2300: Duplicate identifier 'WEBSQL'.
typings/browser/ambient/localForage/localForage.d.ts(48,5): error TS2300: Duplicate identifier 'INDEXEDDB'.
typings/browser/ambient/localForage/localForage.d.ts(96,5): error TS2300: Duplicate identifier 'default'.
typings/main/ambient/localForage/localForage.d.ts(10,5): error TS2300: Duplicate identifier 'driver'.
typings/main/ambient/localForage/localForage.d.ts(12,5): error TS2300: Duplicate identifier 'name'.
typings/main/ambient/localForage/localForage.d.ts(14,5): error TS2300: Duplicate identifier 'size'.
typings/main/ambient/localForage/localForage.d.ts(16,5): error TS2300: Duplicate identifier 'storeName'.
typings/main/ambient/localForage/localForage.d.ts(18,5): error TS2300: Duplicate identifier 'version'.
typings/main/ambient/localForage/localForage.d.ts(20,5): error TS2300: Duplicate identifier 'description'.
typings/main/ambient/localForage/localForage.d.ts(24,5): error TS2300: Duplicate identifier '_driver'.
typings/main/ambient/localForage/localForage.d.ts(28,5): error TS2300: Duplicate identifier '_support'.
typings/main/ambient/localForage/localForage.d.ts(46,5): error TS2300: Duplicate identifier 'LOCALSTORAGE'.
typings/main/ambient/localForage/localForage.d.ts(47,5): error TS2300: Duplicate identifier 'WEBSQL'.
typings/main/ambient/localForage/localForage.d.ts(48,5): error TS2300: Duplicate identifier 'INDEXEDDB'.
typings/main/ambient/localForage/localForage.d.ts(96,5): error TS2300: Duplicate identifier 'default'.
Now I'm wondering how to fix this. I assume that removing either the contents of the browser folder or the ambient one would fix this, but is it the way to do?
Am I missing some other flag?
Or do I need to create some other type of module (i.e., non-ambient) like https://github.com/typings/typed-debug from the info I have on DefinitelyTyped?
Any pointers will be very appreciated :)
How do I actually view it?
I've been poking around but can't seem to find the documentation for writings typings.json
files. I've got some basics in place but need to do something a bit different. I need a repo to not have a main
but instead a list of d.ts files that it exports. I'm thinking I could add a files
property and list them, but I can't find any docs to confirm that.
i am trying to install typings using script command in npm : typings install && typings prune
I get the following error:
https://api.typings.org/entries/dt/core-js/tags/0.0.0%2B20160914114559 responded with 502, expected it to equal 200
Things i have tried is
Even then i am getting the above error, i suspect it is a proxy issue. Can someone please help me resolve this
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.