Feature/smart video

.babelrc.js

@@ -0,0 +1,34 @@
+
+let path = require('path');
+
+function useLocal(module) {
+ return require.resolve(module, {
+ paths: [
+ __dirname
+ ]
+ })
+}
+
+module.exports = {
+ "presets": [
+ [
+ useLocal('@babel/preset-env'),
+ {
+ "targets": {
+ "browsers": [
+ "chrome >= 61",
+ "safari >=8",
+ "edge >= 14",
+ "ff >= 57",
+ "ie >= 10",
+ "ios >= 8"
+ ]
+ }
+ }
+ ]
+ ],
+ "plugins": [
+ path.resolve(__dirname, './plugins/pbjsGlobals.js'),
+ useLocal('babel-plugin-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:8.9.0
+
+ # 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-cli
+ # 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 --nolintfix

.eslintrc.js

@@ -1,3 +1,6 @@
+
+const allowedModules = require("./allowedModules");
+
 module.exports = {
  "env": {
  "browser": true,
@@ -11,6 +14,9 @@ module.exports = {
  }
  },
  "extends": "standard",
+ "plugins": [
+ "prebid"
+ ],
  "globals": {
  "$$PREBID_GLOBAL$$": false
  },
@@ -26,11 +32,16 @@ module.exports = {
  // Violations of these styles should be fixed, and the exceptions removed over time.
  //
  // See Issue #1111.
- "camelcase": "off",
  "eqeqeq": "off",
  "no-return-assign": "off",
  "no-throw-literal": "off",
  "no-undef": "off",
  "no-useless-escape": "off",
- }
+ },
+ "overrides": Object.keys(allowedModules).map((key) => ({
+ "files": key + "/**/*.js",
+ "rules": {
+ "prebid/validate-imports": ["error", allowedModules[key]]
+ }
+ }))
 };

.github/stale.yml

@@ -8,6 +8,7 @@ exemptLabels:
  - security
  - bug
  - feature
+ - on hold
 # 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

.gitignore

@@ -28,6 +28,9 @@ build/coverage/
 .idea/
 # if you remove the above rule, at least ignore the following:
 
+# VS Code
+.vscode/
+
 # User-specific stuff:
 # .idea/workspace.xml
 # .idea/tasks.xml

.nvmrc

@@ -1 +1 @@
-7.0
+8.9

CONTRIBUTING.md

@@ -4,7 +4,7 @@ commit your changes, and [open a pull request](https://help.github.com/articles/
 master branch.
 
 Pull requests must have 80% code coverage before beign considered for merge.
-Additional details about the process can be found [here](./pr_review.md).
+Additional details about the process can be found [here](./PR_REVIEW.md).
 
 ## Issues
 [prebid.org](http://prebid.org/) contains documentation that may help answer questions you have about using Prebid.js.
@@ -55,7 +55,7 @@ When you are adding code to Prebid.js, or modifying code that isn't covered by a
 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:
 
@@ -64,8 +64,8 @@ A test module might have the following general structure:
 import { expect } from 'chai'; // may prefer 'assert' in place of 'expect'
 import adapter from 'src/adapters/<adapter>';
 
-describe('<Adapter>', () => {
- it('<description of unit or feature being tested>', () => {
+describe('<Adapter>', function () {
+ it('<description of unit or feature being tested>', function () {
  // Arrange - set up preconditions and inputs
  // Act - call or act on the code under test
  // Assert - use chai to check that expected results have occurred

PREBID_VERSIONING_DEPRECATION.md

@@ -0,0 +1,25 @@
+# Prebid versioning and deprecation policy
+
+## Goals
+Provide clear definitions and policy around versioning and breaking changes to APIs that are both publisher and demand partner facing.
+
+ - Limit the number of breaking changes.
+ - Ensure significant time for updates for breaking changes so that publisher or demand partners do not break.
+ - Provide a path to deprecation and reduce technical debt and increase security.
+ - Major versions should not be changed more than once per 30 days.
+
+## Versioning
+
+Follow semantic versioning so that all breaking changes occur within a major release. A breaking change includes both demand partner internal APIs* and publisher facing APIs (global APIs).
+
+*Demand partner APIs may be excluded from breaking change policy at the core teams discretion if the changes are made so to be transparent to the bidders (such as internal refactoring).
+
+## Deprecation process
+
+ - Open an issue with an "intent to implement" and "API impact" labels.
+ - Allow 2 weeks for discussion.
+ - Announce breaking change to the mailing list (TBD needs to be created).
+ - At least 2 core members needs to provide explicit approval for the deprecation.
+ - Open a PR against current master for console warning for possible breakage.
+ - Support the previous major version for a minimum of 30 days.
+ - Coordinate with the core team to ensure clean merging into feature branch if applicable (future major version branch).

PR_REVIEW.md

@@ -14,10 +14,16 @@ For modules and core platform updates, the initial reviewer should request an ad
 - 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. 
+ - Below are some examples of bidder specific updates that should require docs update (in their dev-docs/bidders/bidder.md file):
+ - Add support for GDPR consentManagement module > add `gdpr_supported: true`
+ - Add support for userId module > add `userId: pubCommon, digitrust, newProviderHere`
+ - Add support for video and/or native mediaTypes > add `media_types: video, native`
+ - Add support for COPPA > add `coppa_supported: true`
 - 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)
+- Add the PR to the appropriate project board (I.E. 1.23.0 Release) for the week, [see](https://github.com/prebid/Prebid.js/projects)
 
 ### New Adapter or updates to adapter process
 - Follow steps above for general review process. In addition, please verify the following:
@@ -39,9 +45,9 @@ For modules and core platform updates, the initial reviewer should request an ad
 ## 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.
+- Review issues and PRs at least once per weekday for new items. Encourage a 48 "SLA" on PRs/issues assigned. Aim for touchpoint once every 48/hours. 
 - 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.
+- For Issues: try to address questions and troubleshooting requests on your own, assigning them to others as needed. Please add labels as appropriate (I.E. bug, question, backlog etc).
 - 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.