• Stars
    star
    261
  • Rank 156,630 (Top 4 %)
  • Language
    JavaScript
  • License
    Other
  • Created over 10 years ago
  • Updated 12 months ago

Reviews

There are no reviews yet. Be the first to send feedback to the community and the maintainers!

Repository Details

Selenium-webdriver based automation in node.js

Nemo-core Build Status

Join the chat at https://gitter.im/paypal/nemo-core JS.ORG Dependency Status devDependency Status

Nemo-core provides a simple way to add selenium automation to your NodeJS web projects. With a powerful configuration ability provided by krakenjs/confit, and plugin architecture, Nemo-core is flexible enough to handle any browser/device automation need.

Nemo-core is built to easily plug into any task runner and test runner. But in this README we will only cover setup and architecture of Nemo-core as a standalone entity.

Getting started

Install

npm install --save-dev nemo-core

Pre-requisites

Webdriver

Please see here for more information about setting up a webdriver. As long as you have the appropriate browser or browser driver (selenium-standalone, chromedriver) on your PATH, the rest of this should work fine.

Nemo-core and Confit in 90 seconds

Nemo-core uses confit - a powerful, expressive and intuitive configuration system - to elegantly expose the Nemo-core and selenium-webdriver APIs.

Direct configuration

If you install this repo you'll get the following in examples/setup.js. Note the NemoCore() constructor is directly accepting the needed configuration, along with a callback function.

NemoCore({
  "driver": {
    "browser": "firefox"
  },
  'data': {
    'baseUrl': 'https://www.paypal.com'
  }
}, function (err, nemo) {
  //always check for errors!
  if (!!err) {
    console.log('Error during Nemo-core setup', err);
  }
  nemo.driver.get(nemo.data.baseUrl);
  nemo.driver.getCapabilities().
    then(function (caps) {
      console.info("Nemo-core successfully launched", caps.caps_.browserName);
    });
  nemo.driver.quit();
});
you can use async/await as well
const Nemo = require('nemo-core');
(async () => {
  const nemo = await Nemo({
    driver: {
      browser: 'firefox'
    },
    data: {
      baseUrl: 'https://www.paypal.com'
    }
  });
  await nemo.driver.get(nemo.data.baseUrl);
  const caps = await nemo.driver.getCapabilities();
  console.log(`nemo-core successfully launched with ${caps.get('browserName')}`);
  await nemo.driver.quit();
})();
make sure to handle errors when using async/await

You can modify the example above to handle errors. Make sure to define nemo outside of your try block, so you can "quit" the driver if an error occurs after nemo has been successfully created

const Nemo = require('nemo-core');
let nemo;
(async () => {
  try {
    nemo = await Nemo({
      driver: {
        browser: 'firefox'
      },
      data: {
        baseUrl: 'https://www.paypal.com'
      }
    });
    await nemo.driver.get(nemo.data.baseUrl);
    throw new Error('artificial error to test error handling!');
    nemo.driver.quit(); // this is not called, but we can call it in our catch block
  } catch (err) {
    console.log(err);
    // attempt to quit the driver in error scenarios
    if (nemo) {
      nemo.driver.quit();
    }
  }
})();

Run it:

$ node examples/setup.js
Nemo-core successfully launched firefox

Using config files

Look at examples/setupWithConfigFiles.js

//passing __dirname as the first argument tells confit to
//look in __dirname + '/config' for config files
NemoCore(__dirname, function (err, nemo) {
  //always check for errors!
  if (!!err) {
    console.log('Error during Nemo-core setup', err);
  }

  nemo.driver.get(nemo.data.baseUrl);
  nemo.driver.getCapabilities().
    then(function (caps) {
      console.info("Nemo-core successfully launched", caps.caps_.browserName);
    });
  nemo.driver.quit();
});

Note the comment above that passing a filesystem path as the first argument to NemoCore() will tell confit to look in that directory + /config for config files.

Look at examples/config/config.json

{
  "driver": {
    "browser": "config:BROWSER"
  },
  "data": {
    "baseUrl": "https://www.paypal.com"
  },
  "BROWSER": "firefox"
}

That is almost the same config as the first example. But notice "config:BROWSER". Yes, confit will resolve that to the config property "BROWSER".

Run this and it will open the Firefox browser:

$ node examples/setup.js
Nemo-core successfully launched firefox

Now run this command:

$ node examples/setupWithConfigDir.js --BROWSER=chrome
Nemo-core successfully launched chrome

Here, confit resolves the --BROWSER=chrome command line argument and overrides the BROWSER value from config.json

Now this command:

$ BROWSER=chrome node examples/setupWithConfigDir.js
Nemo-core successfully launched chrome

Here, confit resolves the BROWSER environment variable and overrides BROWSER from config.json

What if we set both?

$ BROWSER=chrome node examples/setupWithConfigDir.js --BROWSER=phantomjs
Nemo-core successfully launched chrome

You can see that the environment variable wins.

Now try this command:

$ NODE_ENV=special node examples/setupWithConfigDir.js
Nemo-core successfully launched phantomjs

Note that confit uses the value of NODE_ENV to look for an override config file. In this case config/special.json:

{
  "driver": {
    "browser": "phantomjs"
  },
  "data": {
    "baseUrl": "https://www.paypal.com"
  }
}

Hopefully this was an instructive dive into the possibilities of Nemo-core + confit. There is more to learn but hopefully this is enough to whet your appetite for now!

Nemo-core and Plugins in 60 Seconds

Look at the example/setupWithPlugin.js file:

NemoCore(basedir, function (err, nemo) {
  //always check for errors!
  if (!!err) {
    console.log('Error during Nemo-core setup', err);
  }
  nemo.driver.getCapabilities().
    then(function (caps) {
      console.info("Nemo-core successfully launched", caps.caps_.browserName);
    });
  nemo.driver.get(nemo.data.baseUrl);
  nemo.cookie.deleteAll();
  nemo.cookie.set('foo', 'bar');
  nemo.cookie.getAll().then(function (cookies) {
    console.log('cookies', cookies);
    console.log('=======================');
  });
  nemo.cookie.deleteAll();
  nemo.cookie.getAll().then(function (cookies) {
    console.log('cookies', cookies);
  });
  nemo.driver.quit();
});

Notice the nemo.cookie namespace. This is actually a plugin, and if you look at the config for this setup:

{
  "driver": {
    "browser": "firefox"
  },
  "data": {
    "baseUrl": "https://www.paypal.com"
  },
  "plugins": {
    "cookie": {
      "module": "path:./nemo-cookie"
    }
  }
}

You'll see the plugins.cookie section, which is loading examples/plugin/nemo-cookie.js as a plugin:

'use strict';

module.exports = {
  "setup": function (nemo, callback) {
    nemo.cookie = {};
    nemo.cookie.delete = function (name) {
      return nemo.driver.manage().deleteCookie(name);
    };
    nemo.cookie.deleteAll = function () {
      return nemo.driver.manage().deleteAllCookies();
    };
    nemo.cookie.set = function (name, value, path, domain, isSecure, expiry) {
      return nemo.driver.manage().addCookie(name, value, path, domain, isSecure, expiry)
    };
    nemo.cookie.get = function (name) {
      return nemo.driver.manage().getCookie(name);
    };
    nemo.cookie.getAll = function () {
      return nemo.driver.manage().getCookies();
    };
    callback(null);

  }
};

Running this example:

$ node examples/setupWithPlugin.js
Nemo-core successfully launched firefox
cookies [ { name: 'foo',
   value: 'bar',
   path: '',
   domain: 'www.paypal.com',
   secure: false,
   expiry: null } ]
=======================
cookies []
$

This illustrates how you can create a plugin, and the sorts of things you might want to do with a plugin.

API

Nemo-core

var nemo = NemoCore([[nemoBaseDir, ][config, ][callback]] | [Confit object]);

@argument nemoBaseDir {String} (optional) - If provided, should be a filesystem path to your test suite. Nemo-core will expect to find a /config directory beneath that. <nemoBaseDir>/config/config.json should have your default configuration (described below). nemoBaseDir can alternatively be set as an environment variable. If it is not set, you need to pass your configuration as the config parameter (see below).

@argument config {Object} (optional) - Can be a full configuration (if nemoBaseDir not provided) or additional/override configuration to what's in your config files.

@argument callback {Function} (optional) - This function will be called once the nemo object is fully resolved. It may be called with an error as the first argument which has important debugging information. So make sure to check for an error. The second argument is the resolved nemo object.

@argument Confit object {Object} (optional) - If a Confit object is passed, the configuration step is skipped and the passed object is used directly.

@returns nemo {Object|Promise} - Promise returned if no callback provided. Promise resolves with the same nemo object as would be given to the callback. The nemo object has the following properties:

{
  "driver": ...
  "plugins": {
    "view": {
      "module": "nemo-view"
    }
  }

You could also have a config that looks like this, and nemo-view will still register itself as nemo.view

{
  "driver": ...
  "plugins": {
    "cupcakes": {
      "module": "nemo-view"
    }
  }

But that's confusing. So please stick to the convention.

Typical usage of Nemo-core constructor

A typical pattern would be to use mocha as a test runner, resolve nemo in the context of the mocha before function, and use the mocha done function as the callback:

var nemo;
describe('my nemo suite', function () {
  before(function (done) {
    NemoCore(config, function (err, resolvedNemo-core) {
        nemo = resolvedNemo-core;
        done(err)
    });
  });
  it('will launch browsers!', function (done) {
    nemo.driver.get('https://www.paypal.com');
    nemo.driver.quit().then(function () {
       done();
    });
  });
});

Configure

Calling Configure will return a promise which resolves as a Confit object. This is the same method Nemo-core calls internally in the basic use case. You might want to call Configure if you are interested in the resolved configuration object but not yet ready to start the webdriver. An example would be if you want to make further changes to the configuration based on what gets resolved, prior to starting the webdriver.

function Configure([nemoBaseDir, ][configOverride])

@argument nemoBaseDir {String} (optional) - If provided, should be a filesystem path. There should be a /config directory beneath that. <nemoBaseDir>/config/config.json should have your default configuration. nemoBaseDir can alternatively be set as an environment variable. If it is not set, you need to pass your configuration as the config parameter (see below).

@argument config {Object} (optional) - Can be a full configuration (if nemoBaseDir not provided) or additional/override configuration to what's in your config files.

@returns {Promise} - Promise resolves as a confit object:

Configuration Input

{
  "driver": { /** properties used by Nemo-core to setup the driver instance **/ },
  "plugins": { /** plugins to initialize **/},
  "data": { /** arbitrary data to pass through to nemo instance **/ }
}

This configuration object is optional, as long as you've got nemoData set as an environment variable (see below).

driver

Here are the driver properties recognized by Nemo-core. This is ALL of them. Please be aware that you really only need to supply "browser" to get things working initially.

browser (optional)

Browser you wish to automate. Make sure that your chosen webdriver has this browser option available. While this is "optional" you must choose a browser. Either use this property or the builders.forBrowser option (see below). If both are specified, builders.forBrowser takes precedence.

local (optional, defaults to false)

Set local to true if you want Nemo-core to attempt to start a standalone binary on your system (like selenium-standalone-server) or use a local browser/driver like Chrome/chromedriver or PhantomJS.

server (optional)

Webdriver server URL you wish to use. This setting will be overridden if you are using builders.usingServer

serverProps (optional/conditional)

Additional server properties required of the 'targetServer'

You can also set args and jvmArgs to the selenium jar process as follows:

"serverProps": {
  "port": 4444,
  "args": ["-firefoxProfileTemplate","/Users/medelman/Desktop/ffprofiles"],
  "jvmArgs": ["-someJvmArg", "someJvmArgValue"]
}

jar (optional/conditional)

Path to your webdriver server Jar file. Leave unset if you aren't using a local selenium-standalone Jar (or similar).

serverCaps (optional)

serverCaps would map to the capabilities here: http://seleniumhq.github.io/selenium/docs/api/javascript/module/selenium-webdriver/index_exports_Capabilities.html

Some webdrivers (for instance ios-driver, or appium) would have additional capabilities which can be set via this variable. As an example, you can connect to saucelabs by adding this serverCaps:

"serverCaps": {
	"username": "medelman",
	"accessKey": "b38e179e-079a-417d-beb8-xyz", //not my real access key
	"name": "Test Suite Name", //sauce labs session name
	"tags": ['tag1','tag2'] //sauce labs tag names
}

proxyDetails (optional)

If you want to run test by setting proxy in the browser, you can use 'proxyDetails' configuration. Following options are available: direct, manual, pac and system. Default is 'direct'. For more information refer : http://seleniumhq.github.io/selenium/docs/api/javascript/module/selenium-webdriver/proxy.html

"proxyDetails" : {
    "method": "manual",
    "args": [{"http": "localhost:9001","ftp":"localhost:9001","https":"localhost:9001"}]
}

builders (optional)

This is a JSON interface to any of the Builder methods which take simple arguments and return the builder. See the Builder class here: http://seleniumhq.github.io/selenium/docs/api/javascript/module/selenium-webdriver/index_exports_Builder.html

Useful such functions are:

  • forBrowser (can take the place of "browser", "local" and "jar" properties above)
  • withCapabilities (can take the place of "serverCaps" above)

The nemo setup routine will prefer these "builder" properties over other abstracted properties above, if there is a conflict.

selenium.version (optional)

Since nemo requires a narrow range of versions of selenium-webdriver, you may have a need to upgrade selenium-webdriver (or downgrade) outside of the supported versions that nemo uses. You can do that by using selenium.version. E.g.

"driver": {
  "browser": "firefox",
  "selenium.version": "^2.53.1"
}

Nemo-core will upgrade its internal dependency to what is set in this property. The npm install will only run if the version specified is not already installed.

custom driver

You can also provide a module, which exports a function that returns a fully formed WebDriver object. To do so, follow this example: #177 (comment)

plugins

Plugins are registered with JSON like the following (will vary based on your plugins)

{
	"plugins": {
		"samplePlugin": {
			"module": "path:plugin/sample-plugin",
			"arguments": [...],
			"priority": 99
		},
		"view": {
			"module": "nemo-view"
		}
	}
}

Plugin.pluginName parameters:

  • module {String} - Module must resolve to a require'able module, either via name (in the case it is in your dependency tree) or via path to the file or directory.

  • arguments {Array} (optional, depending on plugin) - Your plugin will be called via its setup method with these arguments: [configArg1, configArg2, ..., ]nemo, callback. Please note that the braces there indicate "optional". The arguments will be applied via Function.apply

  • priority {Number} (optional, depending on plugin) - A priority value of < 100 will register this plugin BEFORE the selenium driver object is created. This means that such a plugin can modify config properties prior to driver setup. Leaving priority unset will register the plugin after the driver object is created.

data

Data will be arbitrary stuff that you might like to use in your tests. In a lot of the examples we set data.baseUrl but again, that's arbitrary and not required. You could pass and use data.cupcakes if you want. Cupcakes are awesome.

Shortstop handlers

Shortstop handlers are data processors that key off of directives in the JSON data. Ones that are enabled in nemo are:

path

use path to prepend the nemoBaseDir (or process.cwd()) to a value. E.g. if nemoBaseDir is .../myApp/tests then a config value of 'path:plugin/myPlugin' will resolve to .../myApp/tests/plugin/myPlugin

env

use env to reference environment variables. E.g. a config value of 'env:PATH' will resolve to /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:...

argv

use argv to reference argv variables. E.g. a config value of 'argv:browser' will resolve to firefox if you set --browser firefox as an argv on the command line

config

Use config to reference data in other parts of the JSON configuration. E.g. in the following config.json:

{
  "driver": {
    ...
  },
  "plugins": {
    "myPlugin": {
      "module": "nemo-some-plugin",
      "arguments": ["config:data.someProp"]
    }
  },
  "data": {
    "someProp": "someVal"
  }
}

The value of plugins.myPlugin.arguments[0] will be someVal

file

Please see https://github.com/krakenjs/shortstop-handlers#handlersfilebasedir-options

base64

Please see https://github.com/krakenjs/shortstop-handlers#handlersbase64

require

Please see https://github.com/krakenjs/shortstop-handlers#handlersrequirebasedir

exec

Please see https://github.com/krakenjs/shortstop-handlers#handlersexecbasedir

glob

Please see https://github.com/krakenjs/shortstop-handlers#handlersglobbasediroptions

Plugins

Authoring a plugin, or using an existing plugin, is a great way to increase the power and usefulness of your Nemo-core installation. A plugin should add its API to the nemo object it receives and passes on in its constructor (see "plugin interface" below)

plugin interface

A plugin should export a setup function with the following interface:

module.exports.setup = function myPlugin([arg1, arg2, ..., ]nemo, callback) {
  ...
  //add your plugin to the nemo namespace
  nemo.myPlugin = myPluginFactory([arg1, arg2, ...]); //adds myMethod1, myMethod2

  //error in your plugin setup
  if (err) {
    callback(err);
    return;
  }
  //continue
  callback(null);
};

When nemo initializes your plugin, it will call the setup method with any arguments supplied in the config plus the nemo object, plus the callback function to continue plugin initialization.

Then in your module where you use Nemo-core, you will be able to access the plugin functionality:

var Nemo-core = require('nemo');
NemoCore({
  'driver': {
    'browser': 'firefox',
    'local': true,
    'jar': '/usr/local/bin/selenium-server-standalone.jar'
  },
  'data': {
    'baseUrl': 'https://www.paypal.com'
  },
  'plugins': {
    'myPlugin': {
      'module': 'path:plugin/my-plugin',
      'arguments': [...]
      'priority': 99
    },
  }
}, function (err, nemo) {
  nemo.driver.get(nemo.data.baseUrl);
  nemo.myPlugin.myMethod1();
  nemo.myPlugin.myMethod2();
  nemo.driver.sleep(5000).
    then(function() {
      console.info('Nemo-core was successful!!');
      nemo.driver.quit();
    });
});

Logging and debugging

Nemo-core uses the debug module for console logging and error output. There are two classes of logging, nemo:log and nemo:error

If you want to see both classes of output, simply use the appropriate value of the DEBUG environment variable when you run nemo:

$ DEBUG=nemo:* <nemo command>

To see just one:

$ DEBUG=nemo:error <nemo command>

Why Nemo-core?

Because we NEed MOre automation testing!

NPM

Unit Tests

  • Unit tests run by default using headless browser PhantomJS. To run unit tests out of box, You must have PhantomJS installed on your system and must be present in the path

    • Download PhantomJS from here
    • On OSX, you can optionally use brew to install PhantomJS like brew install phantomjs
    • PhantomJS installation detailed guide on Ubuntu can be found here
  • If you want to run unit tests on your local browser, like lets say Firefox/Chrome (make sure ChromeDriver is in current path), you need to update browser in unit test configuration, for example the browser section under test/config/config.json like here

  • How to run unit tests?

    • npm test will run unit tests as well as lint task
    • grunt simplemocha will just run unit tests
    • grunt - default grunt task will run linting as well as unit tests
    • To run directly using mocha assuming its globally installed on your system mocha -t 60s
    • Or a specific test, mocha --grep @allArgs@ -t 60s
    • Or post npm install on nemo module, you can run node_modules/.bin/mocha --grep @allArgs@ -t 60s

More Repositories

1

glamorous

DEPRECATED: πŸ’„ Maintainable CSS with React
JavaScript
3,640
star
2

junodb

JunoDB is PayPal's home-grown secure, consistent and highly available key-value store providing low, single digit millisecond, latency at any scale.
Go
2,565
star
3

accessible-html5-video-player

Accessible HTML5 Video Player
JavaScript
2,451
star
4

react-engine

a composite render engine for universal (isomorphic) express apps to render both plain react views and react-router views
JavaScript
1,449
star
5

squbs

Akka Streams & Akka HTTP for Large-Scale Production Deployments
Scala
1,433
star
6

PayPal-node-SDK

node.js SDK for PayPal RESTful APIs
JavaScript
1,279
star
7

paypal-checkout-components

please submit Issues about the PayPal JS SDK here: https://github.com/paypal/paypal-js/issues
JavaScript
1,270
star
8

gatt

Gatt is a Go package for building Bluetooth Low Energy peripherals
Go
1,135
star
9

PayPal-iOS-SDK

Accept credit cards and PayPal in your iOS app
Objective-C
974
star
10

gnomon

Utility to annotate console logging statements with timestamps and find slow processes
JavaScript
932
star
11

PayPal-Android-SDK

Accept PayPal and credit cards in your Android app
Java
824
star
12

bootstrap-accessibility-plugin

Accessibility Plugin for Bootstrap 3 and Bootstrap 3 as SubModule
HTML
789
star
13

PayPal-Python-SDK

Python SDK for PayPal RESTful APIs
Python
702
star
14

AATT

Automated Accessibility Testing Tool
JavaScript
601
star
15

PayPal-Ruby-SDK

Ruby SDK for PayPal RESTful APIs
Ruby
593
star
16

ipn-code-samples

PHP
561
star
17

seifnode

C++
545
star
18

PayPal-NET-SDK

.NET SDK for PayPal's RESTful APIs
C#
535
star
19

PayPal-Java-SDK

Java SDK for PayPal RESTful APIs
Java
535
star
20

data-contract-template

Template for a data contract used in a data mesh.
460
star
21

Checkout-PHP-SDK

PHP SDK for Checkout RESTful APIs
PHP
418
star
22

hera

High Efficiency Reliable Access to data stores
Go
289
star
23

SeLion

Enabling Test Automation in Java
Java
281
star
24

support

An evented server framework designed for building scalable and introspectable services, built at PayPal.
Python
261
star
25

PayPal-Cordova-Plugin

PayPal SDK Cordova/Phonegap Plugin
Objective-C
248
star
26

gimel

Big Data Processing Framework - Unified Data API or SQL on Any Storage
Scala
245
star
27

scala-style-guide

Style Guidelines for PayPal Scala Applications
240
star
28

merchant-sdk-php

PHP SDK for integrating with PayPal's Express Checkout / MassPay / Web Payments Pro APIs
PHP
230
star
29

paypal-js

Loading wrapper and TypeScript types for the PayPal JS SDK
TypeScript
229
star
30

paypal-rest-api-specifications

This repository contains the specification files for PayPal REST APIs.
192
star
31

resteasy-spring-boot

RESTEasy Spring Boot Starter
Java
188
star
32

Checkout-Java-SDK

PayPal Checkout Java SDK
Java
182
star
33

autosklearn-zeroconf

autosklearn-zeroconf is a fully automated binary classifier. It is based on the AutoML challenge winner auto-sklearn. Give it a dataset with known outcomes (labels) and it returns a list of predicted outcomes for your new data. It even estimates the precision for you! The engine is tuning massively parallel ensemble of machine learning pipelines for best precision/recall.
Python
171
star
34

skipto

SkipTo is a replacement for your old classic "Skipnav" link. Once installed on a site, the script dynamically determines the most important places on the page and presents them to the user in a drop-down menu.
HTML
152
star
35

TLS-update

Documentation & tools for the upcoming TLSv1.2 required update
Java
148
star
36

Checkout-NET-SDK

.NET SDK for Checkout RESTful APIs
C#
139
star
37

cascade

Common Libraries & Patterns for Scala Apps @ PayPal
Scala
129
star
38

merchant-sdk-ruby

Ruby
110
star
39

heap-dump-tool

Tool to sanitize data from Java heap dumps.
Java
110
star
40

NNAnalytics

NameNodeAnalytics is a self-help utility for scouting and maintaining the namespace of an HDFS instance.
Java
110
star
41

paypal-smart-payment-buttons

Smart Payment Buttons
JavaScript
108
star
42

yurita

Anomaly detection framework @ PayPal
Scala
106
star
43

InnerSourceCommons

DEPRECATED - old repo for InnerSourceCommons website. Moved to https://github.com/InnerSourceCommons/innersourcecommons.org
JavaScript
105
star
44

adaptivepayments-sdk-php

PHP SDK for integrating with PayPal's AdaptivePayments API
PHP
101
star
45

fullstack-phone

A dual-module phone number system with dynamic regional metadata ☎️
JavaScript
90
star
46

sdk-core-php

for classic PHP SDKs.
PHP
87
star
47

paypal-here-sdk-android-distribution

Add credit card (swipe & key-in) capabilities to your Android app
Java
84
star
48

merchant-sdk-dotnet

C#
83
star
49

paypal-here-sdk-ios-distribution

Add credit card (tap, insert, swipe & key-in) capabilities to your iOS app
Objective-C
82
star
50

payflow-gateway

Repository to store the Payflow Gateway and PayPal Payments Pro SDKs.
C#
80
star
51

sdk-packages

Binary packages for deprecated SDKs.
77
star
52

android-checkout-sdk

Kotlin
77
star
53

Iguanas

Iguanas is a fast, flexible and modular Python package for generating a Rules-Based System (RBS) for binary classification use cases.
Jupyter Notebook
74
star
54

paypal-android

One merchant integration point for all of PayPal's services
Kotlin
72
star
55

legalize.js

JavaScript object validation for browsers + node
JavaScript
70
star
56

paypalcheckout-ios

Need to add Native Checkout to your iOS Application? We can help!
Ruby
70
star
57

paypal-sdk-client

Shared config for PayPal/Braintree client SDKs
JavaScript
65
star
58

load-watcher

Load watcher is a cluster-wide aggregator of metrics, developed for Trimaran: Real Load Aware Scheduler in Kubernetes.
Go
63
star
59

dce-go

Docker Compose Executor to launch pod of docker containers in Apache Mesos.
Go
63
star
60

merchant-sdk-java

Java SDK for integrating with PayPal's Express Checkout / MassPay / Web Payments Pro APIs
Java
62
star
61

sdk-core-java

for classic Java SDKs.
Java
61
star
62

paypal-ios

One merchant integration point for all of PayPal's services
Swift
59
star
63

gorealis

Version 1 of a Go library for interacting with the Aurora Scheduler
Go
58
star
64

scorebot

CSS
57
star
65

PPExtensions

Set of iPython and Jupyter extensions to improve user experience
Python
50
star
66

paypal-checkout-demo

Demo app for paypal-checkout
JavaScript
49
star
67

dione

Dione - a Spark and HDFS indexing library
Scala
49
star
68

Payouts-PHP-SDK

PHP SDK for Payouts RESTful APIs
PHP
49
star
69

pdt-code-samples

Visual Basic
48
star
70

butterfly

Application transformation tool
Java
47
star
71

Payouts-NodeJS-SDK

NodeJS SDK for Payouts RESTful APIs
JavaScript
47
star
72

digraph-parser

Java parser for digraph DSL (Graphviz DOT language)
Java
44
star
73

paypalhttp_php

PHP
43
star
74

tech-talks

Place for all PayPalX presentations, tech talks, and tutorials, and the sample code and apps used in those.
ColdFusion
38
star
75

Illuminator

iOS Automator
Swift
38
star
76

paypal-sdk-release

Unified SDK wrapper module for tests, shared build config, and deploy
JavaScript
37
star
77

PayPal-REST-API-issues

Issue tracking for REST API bugs, features, and documentation requests.
37
star
78

paypal-messaging-components

PayPal JavaScript SDK - messaging components
JavaScript
37
star
79

ionet

ionet is a bridge between the Go stdlib's net and io packages
Go
37
star
80

paypal-access

Examples and code for PayPal Access
Python
36
star
81

horizon

An SBT plugin to help with building, testing, analyzing and releasing Scala
Scala
35
star
82

Payouts-Java-SDK

Java SDK for Payouts RESTful APIs
Java
35
star
83

genio

Genio is an extensible tool that can generate code to consume APIs in multiple programming languages based on different API specification formats.
Ruby
35
star
84

mirakl-hyperwallet-connector

The Hyperwallet Mirakl Connector (HMC) is a self-hosted solution that mediates between a Mirakl marketplace solution and the Hyperwallet (PayPal) payout platform.
Java
34
star
85

openapilint

Node.js linter for OpenAPI specs
JavaScript
31
star
86

paypal-sdk-constants

JavaScript
27
star
87

sdk-core-ruby

Core Library for PayPal Ruby SDKs
Ruby
27
star
88

go.crypto

Go crypto packages
Go
26
star
89

PayPal-PHP-SDK

PHP SDK for PayPal RESTful APIs
PHP
26
star
90

nemo-view

View interface for the Nemo automation framework
JavaScript
26
star
91

Gibberish-Detector-Java

A small program to detect gibberish using a Markov Chain
Java
26
star
92

nemo-accessibility

Automate Accessibility testing within your environment (Localhost)
JavaScript
25
star
93

Payouts-Python-SDK

Python SDK for Payouts RESTful APIs
Python
25
star
94

here-sideloader-api-samples

Sideloader API samples that enable to integrate PayPal Here into other apps
Objective-C
24
star
95

couchbasekafka

Couchbase Kafka Adapter
Java
24
star
96

baler

Bundle assets into iOS static libraries
Python
22
star
97

invoice-sdk-php

PHP SDK for integrating with PayPal's Invoicing API
PHP
21
star
98

Payouts-DotNet-SDK

DotNet SDK for Payouts RESTful APIs
C#
20
star
99

paypal-funding-components

PayPal JavaScript SDK Funding Components
JavaScript
20
star
100

squbs-scala-seed.g8

Scala giter8 Template for Squbs
Scala
20
star