Add triplelift to prebid

.babelrc

@@ -1,4 +1,19 @@
 {
-	"presets": ["es2015"],
-	"plugins": ["transform-object-assign", "transform-es3-property-literals", "transform-es3-member-expression-literals"]
+	"presets": [
+		["env", {
+			"targets": {
+				"browsers": [
+					"chrome >= 61", 
+					"safari >=8", 
+					"edge >= 14", 
+					"ff >= 57", 
+					"ie >= 10",
+					"ios >= 8"
+				]
+			}
+		}]
+	],
+	"plugins": [
+		"transform-object-assign"
+	]
 }

.circleci/config.yml

@@ -0,0 +1,50 @@
+# Javascript Node CircleCI 2.0 configuration file
+#
+# Check https://circleci.com/docs/2.0/language-javascript/ for more details
+#
+version: 2
+jobs:
+  build:
+    docker:
+      # specify the version you desire here
+      - image: circleci/node:7.10
+
+      # Specify service dependencies here if necessary
+      # CircleCI maintains a library of pre-built images
+      # documented at https://circleci.com/docs/2.0/circleci-images/
+      # - image: circleci/mongo:3.4.4
+
+    working_directory: ~/Prebid.js
+
+    steps:
+      - checkout
+
+      # Download and cache dependencies
+      - restore_cache:
+          keys:
+          - v1-dependencies-{{ checksum "package.json" }}
+          # fallback to using the latest cache if no exact match is found
+          - v1-dependencies-
+
+      - run: npm install
+
+      - save_cache:
+          paths:
+            - node_modules
+          key: v1-dependencies-{{ checksum "package.json" }}
+
+      - run: sudo npm install -g gulp
+      # Download and run BrowserStack local
+      - run:
+          name : Download BrowserStack Local binary and start it.
+          command : |
+            # Download the browserstack binary file
+            wget "https://www.browserstack.com/browserstack-local/BrowserStackLocal-linux-x64.zip"
+            # Unzip it
+            unzip BrowserStackLocal-linux-x64.zip
+            # Run the file with user's access key
+            ./BrowserStackLocal ${BROWSERSTACK_ACCESS_KEY} &
+      # run tests!
+      - run: 
+          name: BrowserStack testing
+          command: gulp test --browserstack

.eslintrc.js

@@ -3,6 +3,13 @@ module.exports = {
     "browser": true,
     "commonjs": true
   },
+  "settings": {
+    "import/resolver": {
+      "node": {
+        "moduleDirectory": ["node_modules", "./"]
+      }
+    }
+  },
   "extends": "standard",
   "globals": {
     "$$PREBID_GLOBAL$$": false
@@ -19,14 +26,10 @@ module.exports = {
     // Violations of these styles should be fixed, and the exceptions removed over time.
     //
     // See Issue #1111.
-    "camelcase": "off",
     "eqeqeq": "off",
-    "no-control-regex": "off",
     "no-return-assign": "off",
     "no-throw-literal": "off",
     "no-undef": "off",
-    "no-use-before-define": "off",
     "no-useless-escape": "off",
-    "standard/no-callback-literal": "off",
   }
 };

.github/PULL_REQUEST_TEMPLATE.md

@@ -11,6 +11,7 @@ Thank you for your pull request. Please make sure this PR is scoped to one chang
 - [ ] Refactoring (no functional changes, no api changes)
 - [ ] Build related changes
 - [ ] CI related changes
+- [ ] Does this change affect user-facing APIs or examples documented on http://prebid.org?
 - [ ] Other
 
 ## Description of change
@@ -32,6 +33,9 @@ Be sure to test the integration with your adserver using the [Hello World](/inte
 - contact email of the adapter’s maintainer
 - [ ] official adapter submission
 
+For any changes that affect user-facing APIs or example code documented on http://prebid.org, please provide:
+
+- A link to a PR on the docs repo at https://github.com/prebid/prebid.github.io/
 
 ## Other information
 <!-- References to related PR or issue #s, @mentions of the person or team responsible for reviewing changes, etc. -->

.github/stale.yml

@@ -0,0 +1,19 @@
+# Number of days of inactivity before an issue becomes stale
+daysUntilStale: 14
+# Number of days of inactivity before a stale issue is closed
+daysUntilClose: 7
+# Issues with these labels will never be considered stale
+exemptLabels:
+  - pinned
+  - security
+  - bug
+  - feature
+# Label to use when marking an issue as stale
+staleLabel: stale
+# Comment to post when marking an issue as stale. Set to `false` to disable
+markComment: >
+  This issue has been automatically marked as stale because it has not had
+  recent activity. It will be closed if no further activity occurs. Thank you
+  for your contributions.
+# Comment to post when closing a stale issue. Set to `false` to disable
+closeComment: false

CONTRIBUTING.md

@@ -48,17 +48,14 @@ When you are adding code to Prebid.js, or modifying code that isn't covered by a
   - _Assert_: check that the expected results have occurred
     - e.g., use Chai assertions to check that the expected output is equal to the actual output
 - Test the public interface, not the internal implementation
-- If using global `pbjs` data structures in your test, take care to not completely overwrite them with your own data as that may affect other tests relying on those structures, e.g.:
-    - **OK**: `pbjs._bidsRequested.push(bidderRequestObject);`
-    - **NOT OK**: `pbjs._bidsRequested = [bidderRequestObject];`
 - If you need to check `adloader.loadScript` in a test, use a `stub` rather than a `spy`. `spy`s trigger a network call which can result in a `script error` and cause unrelated unit tests to fail. `stub`s will let you gather information about the `adloader.loadScript` call without affecting external resources
 - When writing tests you may use ES2015 syntax if desired
 
 ### Test Examples
 Prebid.js already has many tests. Read them to see how Prebid.js is tested, and for inspiration:
 
 - Look in `test/spec` and its subdirectories
-- Tests for bidder adaptors are located in `test/spec/adapters`
+- Tests for bidder adaptors are located in `test/spec/modules`
 
 A test module might have the following general structure:
 

PR_REVIEW.md

@@ -0,0 +1,48 @@
+## Summary
+We take PR review seriously. Please read https://medium.com/@mrjoelkemp/giving-better-code-reviews-16109e0fdd36#.xa8lc4i23 to understand how a PR review should be conducted. Be rational and strict in your review, make sure you understand exactly what the submitter's intent is. Anyone in the community can review a PR, but a Prebid Org member is also required. A Prebid Org member should take ownership of a PR and do the initial review.
+
+If the PR is for a standard bid adapter or a standard analytics adapter, just the one review from a core member is sufficient. The reviewer will check against [required conventions](http://prebid.org/dev-docs/bidder-adaptor.html#required-adapter-conventions) and may merge the PR after approving and confirming that the documentation PR against prebid.org is open and linked to the issue.
+
+For modules and core platform updates, the initial reviewer should request an additional team member to review as a sanity check. Merge should only happen when the PR has 2 `LGTM` from the core team and a documentation PR if required.
+
+### General PR review Process
+- Checkout the branch (these instructions are available on the github PR page as well).
+- Verify PR is a single change type. Example, refactor OR bugfix. If more than 1 type, ask submitter to break out requests.
+- Verify code under review has at least 80% unit test coverage. If legacy code has no unit test coverage, ask for unit tests to be included in the PR.
+- Verify tests are green in Travis-ci + local build by running `gulp serve` | `gulp test`
+- Verify no code quality violations are present from linting (should be reported in terminal)
+- Review for obvious errors or bad coding practice / use best judgement here.
+- If the change is a new feature / change to core prebid.js - review the change with a Tech Lead on the project and make sure they agree with the nature of change.
+- If the change results in needing updates to docs (such as public API change, module interface etc), add a label for "needs docs" and inform the submitter they must submit a docs PR to update the appropriate area of Prebid.org **before the PR can merge**. Help them with finding where the docs are located on prebid.org if needed. 
+- If all above is good, add a `LGTM` comment and request 1 additional core member to review.
+- Once there is 2 `LGTM` on the PR, merge to master
+- Ask the submitter to add a PR for documentation if applicable.
+- Add a line into the [draft release](https://github.com/prebid/Prebid.js/releases) notes for this submission. If no draft release is available, create one using [this template]( https://gist.github.com/mkendall07/c3af6f4691bed8a46738b3675cb5a479)
+
+### New Adapter or updates to adapter process
+- Follow steps above for general review process. In addition, please verify the following:
+- Verify that bidder has submitted valid bid params and that bids are being received.
+- Verify that bidder is not manipulating the prebid.js auction in any way or doing things that go against the principles of the project. If unsure check with the Tech Lead.
+- Verify that  the bidder is being as efficient as possible, ideally not loading an external library, however if they do load a library it should be cached.
+- Verify that code re-use is being done properly and that changes introduced by a bidder don't impact other bidders.
+- If the adapter being submitted is an alias type, check with the bidder contact that is being aliased to make sure it's allowed.
+- If the adapter is triggering any user syncs make sure they are using the user sync module in the Prebid.js core.
+- Requests to the bidder should support HTTPS
+- Responses from the bidder should be compressed (such as gzip, compress, deflate)
+- Bid responses may not use JSONP: All requests must be AJAX with JSON responses
+- All user-sync (aka pixel) activity must be registered via the provided functions
+- Adapters may not use the $$PREBID_GLOBAL$$ variable
+- All adapters must support the creation of multiple concurrent instances. This means, for example, that adapters cannot rely on mutable global variables.
+- Adapters may not globally override or default the standard ad server targeting values: hb_adid, hb_bidder, hb_pb, hb_deal, or hb_size, hb_source, hb_format.
+- After a new adapter is approved, let the submitter know they may open a PR in the [headerbid-expert repository](https://github.com/prebid/headerbid-expert) to have their adapter recognized by the [Headerbid Expert extension](https://chrome.google.com/webstore/detail/headerbid-expert/cgfkddgbnfplidghapbbnngaogeldmop). The PR should be to the [bidder patterns file](https://github.com/prebid/headerbid-expert/blob/master/bidderPatterns.js), adding an entry with their adapter's name and the url the adapter uses to send and receive bid responses.
+
+## Ticket Coordinator
+
+Each week, Prebid Org assigns one person to keep an eye on incoming issues and PRs. That person should:
+- Review issues and PRs at least once per weekday for new items.
+- For PRs: assign PRs to individuals on the PR review list. Try to be equitable -- not all PRs are created equally. Use the "Assigned" field and add the "Needs Review" label.
+- For Issues: try to address questions and troubleshooting requests on your own, assigning them to others as needed.
+- Issues that are questions or troubleshooting requests may be closed if the originator doesn't respond within a week to requests for confirmation or details.
+- Issues that are bug reports should be left open and assigned to someone in PR rotation to confirm or deny the bug status.
+- It's polite to check with others before assigning them large tasks.
+- If possible, check in on older items and see if they can be unstuck.

README.md

@@ -1,4 +1,4 @@
-[![Build Status](https://travis-ci.org/prebid/Prebid.js.svg?branch=master)](https://travis-ci.org/prebid/Prebid.js)
+[![Build Status](https://circleci.com/gh/prebid/Prebid.js.svg?style=svg)](https://circleci.com/gh/prebid/Prebid.js)
 [![Percentage of issues still open](http://isitmaintained.com/badge/open/prebid/Prebid.js.svg)](http://isitmaintained.com/project/prebid/Prebid.js "Percentage of issues still open")
 [![Average time to resolve an issue](http://isitmaintained.com/badge/resolution/prebid/Prebid.js.svg)](http://isitmaintained.com/project/prebid/Prebid.js "Average time to resolve an issue")
 [![Code Climate](https://codeclimate.com/github/prebid/Prebid.js/badges/gpa.svg)](https://codeclimate.com/github/prebid/Prebid.js)
@@ -26,11 +26,7 @@ Working examples can be found in [the developer docs](http://prebid.org/dev-docs
 
     $ git clone https://github.com/prebid/Prebid.js.git
     $ cd Prebid.js
-    $ yarn install
-
-Prebid supports the `yarn` npm client. This is an alternative to using `npm` for package management, though `npm install` will continue to work as before.
-
-For more info, see [the Yarn documentation](https://yarnpkg.com).
+    $ npm install
 
 *Note:* You need to have `NodeJS` 4.x or greater installed.
 
@@ -60,11 +56,8 @@ For example, when running the serve command: `gulp serve --modules=openxBidAdapt
 Building with just these adapters will result in a smaller bundle which should allow your pages to load faster.
 
 **Build standalone prebid.js**
-Prebid now supports the `yarn` npm client. This is an alternative to using `npm` for package management, though `npm` will continue to work as before.
-
-For more info about yarn see https://yarnpkg.com
 
-- Clone the repo, run `yarn install`
+- Clone the repo, run `npm install`
 - Then run the build:
 
         $ gulp build --modules=openxBidAdapter,rubiconBidAdapter,sovrnBidAdapter
@@ -82,11 +75,11 @@ With `modules.json` containing the following
 ]
 ```
 
-**Build prebid.js using Yarn for bundling**
+**Build prebid.js using npm for bundling**
 
-In case you'd like to explicitly show that your project uses `prebid.js` and want a reproducible build, consider adding it as an `yarn` dependency.
+In case you'd like to explicitly show that your project uses `prebid.js` and want a reproducible build, consider adding it as an `npm` dependency.
 
-- Add `prebid.js` as a `yarn` dependency of your project: `yarn add prebid.js`
+- Add `prebid.js` as a `npm` dependency of your project: `npm install prebid.js`
 - Run the `prebid.js` build under the `node_modules/prebid.js/` folder
 
         $ gulp build --modules=path/to/your/list-of-modules.json
@@ -113,11 +106,6 @@ To run the unit tests:
 ```bash
 gulp test
 ```
-To run tests for a single file:
-
-```bash
-gulp test --file "path/to/spec/file.js"
-```
 
 To generate and view the code coverage reports: