Git Product home page Git Product logo

mocha-chrome's Introduction

tests size libera manifesto

mocha-chrome

☕ Run Mocha tests using headless Google Chrome

Requirements

mocha-chrome requires Node v8.0.0 or higher.

mocha-chrome is a development tool, which means you can use tools like NVM and nodenv to manage your installed versions, and temporarily switch to v8+ to run tests on your machine. Most modern CI environments also support specifying the version of Node to run.

Getting Started

To begin, you'll need to install mocha-chrome:

$ npm install mocha-chrome --save-dev

Then you'll need a local npm install of mocha:

$ npm install mocha --save-dev

To run the tests, you'll need an HTML file with some basics:

<!doctype>
<html>
  <head>
    <title>Test</title>
    <meta charset="utf-8">
    <link rel="stylesheet" href="../../node_modules/mocha/mocha.css" />
    <script src="../../node_modules/mocha/mocha.js"></script>
    <script src="../../node_modules/chai/chai.js"></script>
  </head>
  <body>
    <div id="mocha"></div>
    <script>
      expect = chai.expect;

      // add tests here

      mocha.run();
    </script>
  </body>
</html>

You can then add your tests either through an external script file or inline within a <script> tag. Running the tests is easy, either with the CLI binary, or programmatically.

CLI

$ mocha-chrome --help

  Usage
    $ mocha-chrome <file.html> [options]

  Options
    --chrome-flags              A JSON string representing an array of flags to pass to Chrome
    --chrome-launcher           Chrome launcher options (see https://github.com/GoogleChrome/chrome-launcher#launchopts)
    --ignore-console            Suppress console logging
    --ignore-exceptions         Suppress exceptions logging
    --ignore-resource-errors    Suppress resource error logging
    --log-level                 Specify a log level; trace, debug, info, warn, error
    --mocha                     A JSON string representing a config object to pass to Mocha
    --no-colors                 Disable colors in Mocha's output
    --reporter                  Specify the Mocha reporter to use
    --timeout                   Specify the test startup timeout to use
    --version

  Examples
  $ mocha-chrome test.html --no-colors
  $ mocha-chrome test.html --reporter dot
  $ mocha-chrome test.html --mocha '\{"ui":"tdd"\}'
  $ mocha-chrome test.html --chrome-flags '["--some-flag", "--and-another-one"]'
  $ mocha-chrome test.html --chrome-launcher.maxConnectionRetries=10

Events

mocha-chrome is technically an event emitter. Due to the asynchronous nature of nearly every interaction with headless Chrome, a simple event bus is used to handle actions from the browser. You have access to those events if running mocha-chrome programatically.

Example usage can be found in both test.js and bin/mocha-chrome.

config

Fired to indicate that mocha-chrome should configure mocha.

ended

Fired when all tests have ended.

Parameters

stats : object - A Mocha stats object. eg:

{
  suites: 1,
  tests: 1,
  passes: 1,
  pending: 0,
  failures: 0,
  start: '2017-08-03T02:12:02.007Z',
  end: '2017-08-03T02:12:02.017Z',
  duration: 10
}

ready

Fired to indicate that the mocha script in the client has been loaded.

resourceFailed

Fired when a resource fails to load.

Parameters

data : object - An object containing information about the resource. eg:

{ url, method, reason }

started

Fired when a resource fails to load.

Parameters

tests : number - The number of tests being run.

width

Fired to indicate that mocha-chrome should inform mocha of the width of the current console/terminal.

Limitations

Reporters

Reporters are limited to those which don't use process.stdout.write to manipulate terminal output. eg. spec, xunit, etc. Examples of reporters which don't presently produce expected output formatting include dot and nyan. The cause of this limitation is the lack of a good means to pipe Mocha's built-in stdout.write through the Chrome Devtools Protocol to mocha-chrome.

Third-Party Reporters

Third party reporters are not currently supported, but support is planned. Contribution on that effort is of course welcome.

Cookies and the file:// Protocol

Chrome has long-since disabled cookies for files loaded via the file:// protocol. The once-available --enable-file-cookies has been removed and we're left with few options. If you're in need of cookie support for your local-file test, you may use the following snippet, which will shim document.cookie with very basic support:

  Object.defineProperty(document, 'cookie', {
    get: function () {
      return this.value || '';
    },
    set: function (cookie) {
      cookie = cookie || '';

      const cutoff = cookie.indexOf(';');
      const pair = cookie.substring(0, cutoff >= 0 ? cutoff : cookie.length);
      const cookies = this.value ? this.value.split('; ') : [];

      cookies.push(pair);

      return this.value = cookies.join('; ');
    }
  });

Continuous Integration

Circle CI

Running on Circle CI requires that Chrome is installed and running in the container your tests are running within. Please refer to this article for details: https://discuss.circleci.com/t/installing-chrome-inside-of-your-docker-container/9067. Alternatively, you can use a pre-built CircleCI image with browsers installed. You'll have to choose a tag with the -browsers suffix from the full tag list.

Travis CI

Please refer to the "Running it all on Travis CI" portion of the guide on Automated testing with Headless Chrome from Google. Though the article primarily addresses Karma, the setup for Travis CI is identical.

As of January 8th, 2018, Travis CI has upgraded from Trusty -> Xenial to address the Meltdown security vulnerability. There are issues with Chrome in Xenial that can currently be worked around with sudo: required. At some point this workaround may be removable. For the near term, please add sudo: required to Travis CI configuration files. See travis-ci/travis-ci#8836. Credit: @smalls.

Testing mocha-chrome

$ npm test

Yep, that's it.

Contributing

We welcome your contributions! Please have a read of CONTRIBUTING.

Attribution

I'd like to thank @nathanboktae for his work on mocha-phantomjs and mocha-phantomjs-core; two projects I've used extensively over the years, and from which the inspiration for this module originates. Many of the nuances of working with mocha in a hosted or connected browser environment were solved within mocha-phantomjs-core and I am personally grateful.

mocha-chrome's People

Contributors

gamtiq avatar hsalokor avatar kamilogorek avatar luiz avatar marko-cekol avatar nathanboktae avatar nicolasletellier avatar pasieronen avatar shellscape avatar smalls avatar the-alchemist avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

mocha-chrome's Issues

Incorrect `mocha.run()` called with no tests

  • Operating System Mac OSX
  • Node Version: 8.5.0
  • NPM Version: 5.5.1
  • mocha Version: 4.0.1
  • mocha-chrome Version: 1.0.0
  • This is a feature request
  • This is a bug

Code

This line of code breaks this. Wouldn't it be better to check number of files?

Expected Behavior

Be able to run tests using requirejs

Actual Behavior

Errors out with mocha.run() called with no tests

Hi, cool library! I'm doing similar stuff as this library and wanted to try it using requirejs. I just hardcoded the started event to emit 1 and it worked :).

net::ERR_INSECURE_RESPONSE when protocol is https

Looks like I stumbled onto a fresh new mocha-chrome, thanks for creating and sharing it.

Any thoughts on how to get it to work on https pages? I get net::ERR_INSECURE_RESPONSE

I tried adding the --ignore-certificate-errors flag to the chrome-launcher options in lib/instance.js but it didn't help.

  • Operating System:
    Mac OS X v10.12.3

  • Node Version:
    v7.7.4

  • NPM Version:
    yarn v0.27.5, npm v5.0.3

  • mocha Version:
    v3.5.0

  • mocha-chrome Version:
    v0.1.1

  • This is a feature request
  • This is a bug

Code

$ mocha-chrome https://localhost:8000
Resource Failed to Load: { url: 'https://localhost:8000/',
  method: 'GET',
  reason: 'net::ERR_INSECURE_RESPONSE' }
[chrome-exception] { timestamp: 1502357619852.674,
  exceptionDetails: 
   { exceptionId: 1,
     text: 'Uncaught',
     lineNumber: 5,
     columnNumber: 8,
     stackTrace: { callFrames: [Object] },
     exception: 
      { type: 'object',
        subtype: 'error',
        className: 'DOMException',
        description: 'DOMException: Failed to read the \'localStorage\' property from \'Window\': Storage is disabled inside \'data:\' URLs.\n    at <anonymous>:6:9\n    at <anonymous>:16:3',
        objectId: '{"injectedScriptId":2,"id":1}',
        preview: [Object] },
     executionContextId: 2 } }
Mocha-Chrome Failed: Failed to load the page. Check the url: https://localhost:8000

Expected Behavior

Actual Behavior

For Bugs; How can we reproduce the behavior?

For Features; What is the motivation and/or use-case for the feature?

how to debug, mocha-chrome not detecting mocha.run

Output:

Mocha-Chrome Failed: mocha was not found in the page within 10000ms of the page loading.
Mocha-Chrome Failed: mocha.run() was not called within 10000ms of the page loading.
  ChromeLauncher Killing Chrome instance 4439 +11s

Thing is, the page works fine when I load it in a browser. I can catch a breakpoint on mocha.run when it is executed, and window.mocha exists (which is what mocha-chrome is looking for). Setting log level to debug doesn't give any more information. How can I debug from here?

Feature request: Pass args to chrome

  • Operating System: Windwos 10
  • Node Version: 8.9.0
  • NPM Version: 5.5.1
  • mocha Version: 2.2.41
  • mocha-chrome Version: 1.0.1
  • This is a feature request
  • This is a bug

For Features; What is the motivation and/or use-case for the feature?

I would like to pass the --allow-file-access-from-files command line argument to the headless instance of chrome. My test web page dynamically loads a json file and I use the above argument when I load the page via file://...

test failures with recent builds of chrome

i'm getting test failures when running with a recent build of chrome (>=71):

> npm run bdd

> [email protected] bdd E:\play\mocha-chrome
> mocha test/test.js --timeout 10000 --exit



  MochaChrome
Mocha-Chrome Failed: mocha was not found in the page within 1000ms of the page loading.
Mocha-Chrome Failed: mocha.run() was not called within 1000ms of the page loading.
    √ fails if mocha isn't loaded (2527ms)
Mocha-Chrome Failed: mocha.run() was not called within 1000ms of the page loading.
    √ fails if mocha.run isn't called (2448ms)
Promise Rejection:  Error: No inspectable targets
    at defaultTarget (E:\play\mocha-chrome\node_modules\chrome-remote-interface\lib\chrome.js:46:23)
    at E:\play\mocha-chrome\node_modules\chrome-remote-interface\lib\chrome.js:232:32
    at process.internalTickCallback (internal/process/next_tick.js:77:7)
    1) runs a test
    √ reports a failure (1408ms)
    √ allows runner modification (1379ms)
    √ supports different reporters (1412ms)
    √ supports mixed tests (1647ms)
    √ reports async failures (1466ms)
    √ supports test using and clearing localStorage (1223ms)
    √ handles circular structures in console.log (1042ms)

  mocha-chrome binary
    √ should report version (1243ms)
    √ should run a successful test (1954ms)
    √ should run a failing test (2335ms)
    √ should default to "spec" reporter (2227ms)
    √ should honor --spec parameter (2207ms)
    √ should allow use of --chrome-flags (2243ms)
    √ should use the --timeout flag value (3752ms)


  16 passing (43s)
  1 failing

  1) MochaChrome
       runs a test:
     Error: Timeout of 10000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves.

mocha-chrome: unexpected token

Please note that this template is not optional. If you proceed with this form,
please fill out all fields, or your issue may be closed as "invalid."
Please do not delete this template. Please do remove this header to acknowledge this message.

  • Operating System: macOS Sierra 10.12.6
  • Node Version: v6.11.3
  • NPM Version: 3.10.10
  • mocha Version: 3.5.3
  • mocha-chrome Version: 0.2.1
  • chrome Version: 61.0.3163.100
  • This is a feature request
  • [x ] This is a bug

Code

  // code

Expected Behavior

mocha-chrome should run tests in html file

Actual Behavior

/Users/robhicks/.nvm/versions/node/v6.11.3/lib/node_modules/mocha-chrome/bin/mocha-chrome:89
(async function run () {
^^^^^^^^

SyntaxError: Unexpected token function
at createScript (vm.js:56:10)
at Object.runInThisContext (vm.js:97:10)
at Module._compile (module.js:542:28)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3)
at Module.runMain (module.js:604:10)
at run (bootstrap_node.js:389:7)
at startup (bootstrap_node.js:149:9)

For Bugs; How can we reproduce the behavior?

Run the mocha-chrome command in an environment like mine.

For Features; What is the motivation and/or use-case for the feature?

Unexpected token function

Please note that this template is not optional. If you proceed with this form,
please fill out all fields, or your issue may be closed as "invalid."
Please do not delete this template. Please do remove this header to acknowledge this message.

  • Operating System: MacOS Sierra (10.12.6 (16G29)
  • Node Version: 6.9.5
  • NPM Version: 5.4.1
  • mocha Version: 3.5.0
  • mocha-chrome Version: 0.2.1
  • This is a feature request
  • This is a bug

Code

foo.spec.js:

describe('Tracker', () => {
  it('Should do two', () => {
    const element = document.createElement('div');
    element.style.width = 500;
    element.style.height = 500;
    document.body.appendChild(element);

    console.log(element.getBoundingClientRect());
    return true;
  });
});

index.html:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <meta http-equiv="X-UA-Compatible" content="ie=edge">
  <title>Tests</title>
  <link rel="stylesheet" href="../node_modules/mocha/mocha.css" />
</head>
<body>
  <div id="mocha"></div>
  <script src="../node_modules/mocha/mocha.js"></script>
  <script src="../node_modules/chai/chai.js"></script>
  <script>
    mocha.ui('bdd');
    mocha.reporter('html');
    var expect = chai.expect;
  </script>

  <!-- Library -->
  <script src="../lib/index.js"></script>

  <!-- Tests -->
  <script src="./foo.spec.js"></script>

  <script>
    mocha.run();
  </script>
</body>
</html>

Run:

node_modules/mocha-chrome/bin/mocha-chrome test/index.html

Executing just mocha-chrome after global installation produces the same error, as mocha-chrome command executes the bin file provided in the example above.

Expected Behavior

Tests should run.

Actual Behavior

Error in the console trying executing the test command:

/Users/azakharchenko/Local/Libraries/sentinel-dom/node_modules/mocha-chrome/bin/mocha-chrome:89
(async function run () {
       ^^^^^^^^
SyntaxError: Unexpected token function
    at Object.exports.runInThisContext (vm.js:76:16)
    at Module._compile (module.js:542:28)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)
    at Module.runMain (module.js:604:10)
    at run (bootstrap_node.js:394:7)
    at startup (bootstrap_node.j

feature request: override default chrome parameters

it would be great if you could override some of the default parameters that are passed to chrome.

currently we have to patch this npm package to remove the --disable-gpu flag, because we specifically want GPU support in our unit tests.

patching the package is a maintenance pain, it would be nice if we could just prevent that default.

Custom reporter suggestion

  • Operating System: Windows 10
  • Node Version: 8.6.0
  • NPM Version: 6.4.1
  • mocha Version: 5.2
  • mocha-chrome Version: 1.1.0
  • [x ] This is a feature request
  • This is a bug

Expected Behavior

My test harness defines a custom reporter for me. This reporter should be used if I don't specify any reporter.

Actual Behavior

The spec reporter is used if I don't specify a reporter.

For Features; What is the motivation and/or use-case for the feature?

There's an easy way to specify custom reporters, just remove the default.

In examining the code, I found this seems to be superfluous, because the config call overwrites this.

    bus.on('ready', content => {
      this.client.Runtime.evaluate({ expression: `mocha.setup({ reporter: 'spec' })`});
    });

If you don't want to change the default behaviour, you could wrap everything in a check where a reporter named custom triggers this behaviour.

With xunit reporter, output is inconsistent, and output option can't be set

  • Operating System: ubuntu 14.04
  • Node Version: 8.11.3
  • NPM Version: 5.6.0
  • mocha Version: 6.1.2
  • mocha-chrome Version: 2.0.0
  • This is a feature request
  • This is a bug

Code

./node_modules/.bin/mocha-chrome --reporter xunit --reporter-options output=report.xml build/index.html

Expected Behavior

xml report written to report.xml

Actual Behavior

xml is written to stdout, and is truncated. There appears to be a race of some sort. From run to run, the output may be two lines or forty lines, but never the complete report.

The reporter works fine outside mocha-chrome, with the xml being output consistently to the console.

For Bugs; How can we reproduce the behavior?

Use xunit reporter.

For Features; What is the motivation and/or use-case for the feature?

The point of xunit reporter is to write results to a machine-readable file for CI. If there's no way to write to a file, it defeats the point. Redirecting stdout to a file works poorly, because other things in the framework write to stdout, corrupting the xml. E.g.

Download the React DevTools and use an HTTP server (instead of a file: URL) for a better development experience: https://fb.me/react-devtools

Ability to save results to file, like mocha-phantomjs

  • Operating System: Windows 10
  • Node Version: v8.11.2
  • NPM Version: v6.1.0
  • mocha Version: v5.2.0
  • mocha-chrome Version: v1.1.0
  • This is a feature request
  • This is a bug

Expected Behavior

Having the ability to save the test results to disk, so you can see the progress in your CI tool.

Actual Behavior

As far as I can see, we can't do this, the reporter will always report on the console.

For Features; What is the motivation and/or use-case for the feature?

To track test progress in our CI tool

Feature request: Allow customization/confguration of the mocha start timeout

  • Operating System: Ubuntu 16.04
  • Node Version: 8.9.3
  • NPM Version: 5.5.1
  • mocha Version: 2.5.3
  • mocha-chrome Version: 1.0.2
  • This is a feature request
  • This is a bug

For Features; What is the motivation and/or use-case for the feature?

Our Continuous Integration machine often needs to run several CI tasks (builds) in parallel, causing slowdown in responses from headless chrome process. This causes the tasks to fail with an error message "Mocha-Chrome Failed: mocha.run() was not called within 1000ms of the page loading."

If the loadTimeout MochaChrome constructor option would be exposed as a CLI switch, we could increase the default timeout to allow for increased load and decreased responsiveness of the chrome.

We've tried using --timeout switch, but it had no effect, so I assume that switch sets the default timeout for each separate unit test.

Unicode characters become garbled on Windows

  • Operating System: Windows 10
  • Node Version: v8.9.3
  • NPM Version: 5.6.0
  • mocha Version: 4.0.1
  • mocha-chrome Version: 1.0.2
  • This is a feature request
  • This is a bug

Code

  // code

Expected Behavior

Mocha test results display in Unicode, similar to the regular mocha command

ClipboardFormats
      ✓ should compile

Actual Behavior

Unicode characters are obscured in output

ClipboardFormats
      ✓ should compile

For Bugs; How can we reproduce the behavior?

Run mocha-chrome on a Windows system, I think, is all that is needed to reproduce the issue

For Features; What is the motivation and/or use-case for the feature?

test failure results in orphaned chrome.exe processes

Please note that this template is not optional. If you proceed with this form,
please fill out all fields, or your issue may be closed as "invalid."
Please do not delete this template. Please do remove this header to acknowledge this message.

  • Operating System: win64
  • Node Version: 10.0.0
  • NPM Version: 5.6.0
  • mocha Version: 3.5.3
  • mocha-chrome Version: 0.2.1
  • This is a bug

Code

Expected Behavior

chrome processes are killed after test failure

Actual Behavior

chrome processes are left running

For Bugs; How can we reproduce the behavior?

i'm pretty sure the issue is due to the fact that exit() is async.

if you add console.log calls and a try/catch to exit, like this:

  async exit (code) {
    console.log('exit ' + code);
    this.closed = true;
    try {
      console.log('close');
      await this.client.close();
      console.log('closed');
    }
    finally {
      console.log('kill');
      await this.instance.kill();
      console.log('killed');
    }

    this.bus.emit('exit', 1);
  }
}

then it only prints close - the process exits before the async close() call returns.

this is because exit isn't awaited:

    bus.on('ended', stats => {
      this.ended = true;
      this.exit(stats.failures);
    });

however, adding an await here:

    bus.on('ended', async stats => {
      this.ended = true;
      await this.exit(stats.failures);
    });

doesn't help because Nanobus doesn't support chaining async methods.

the runner looks like this:

  grunt.registerMultiTask('mochaChrome', async function() {
    var done = this.async();

    try {
      var options = this.data.options;

      for (var testURL of options.urls) {
        var my_opts = Object.assign({}, options);
        my_opts.urls = undefined;
        my_opts.url = testURL;
        my_opts.chromeFlags = ['--no-sandbox', '--mute-audio'];
        my_opts.logLevel = 'trace';
        var runner = new MochaCrome(my_opts);
        var result = new Promise((resolve, reject) => {
          runner.on('ended', function(stats) {
            if (stats.failures) {
              reject(stats);
            } else {
              resolve(stats);
            }
          });
          runner.on('failure', reject);
        });

        (async function () {
          await runner.connect();
          await runner.run();
        })();

        await result;
      }

      done();
    }
    catch (e) {
      if (e instanceof Error) {
        done(e);
      } else {
        done(new Error(e));
      }
    }
  })

Add support of Node 6.x

Would it be possible to add support of Node 6.x ?
It is the current LTS and people in large companies (like myself) might be stuck on it. That would be a shame to not let them use this nice libary :)

mocha's output is always uncolorified

  • Operating System (or Browser): macOS Mojave, Chrome
  • Node Version: 10.15.3
  • mocha-chrome Version: 2.1.0

How Do We Reproduce?

Call

mocha-chrome http://some-server/some-path/some-page.html

Then call

mocha-chrome http://some-server/some-path/some-page.html --no-colors

Expected Behavior

mocha's output from the first call should be colorified.
mocha's output from the second call shouldn't be colorified.

Actual Behavior

mocha's output from both calls is uncolorified.

This problem was introduced by ffe4d83.
The correct fix is in #38.

Add a pre exit hook

  • This is a feature request

For Features; What is the motivation and/or use-case for the feature?

To be able to extract coverage I have to override exit like this

async exit(code) {
    const { Runtime } = runner.client;
    const { result: { value }} = await Runtime.evaluate({ expression: 'window.__coverage__', returnByValue: true });
    this.closed = true;
    await this.client.close();
    await this.instance.kill();

    this.bus.emit('exit', 1);
  }

it would be nice to have some kind of pre exit hook instead

async evaluateExit() {
  await Promise.resolve();
}

this way I don't have to worry about changes in the existing MochaChrome. Maybe even send this with options so I don't have to extend the class.

const runner = new MochaChrome({
  async preExitHook() {
    const { result: { value }} = await Runtime.evaluate({ expression: 'window.__coverage__', 
  }
});

Let me know if you need more info.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.