fix conflicts

.babelrc.js

@@ -20,7 +20,7 @@ module.exports = {
             "safari >=8",
             "edge >= 14",
             "ff >= 57",
-            "ie >= 10",
+            "ie >= 11",
             "ios >= 8"
           ]
         }

.github/release-drafter.yml

@@ -0,0 +1,28 @@
+
+name-template: 'Prebid $RESOLVED_VERSION Release'
+tag-template: '$RESOLVED_VERSION'
+categories:
+  - title: '🚀 New Features'
+    label: 'feature'
+  - title: '🛠 Maintenance'
+    label: 'maintenance'    
+  - title: '🐛 Bug Fixes'
+    labels:
+      - 'fix'
+      - 'bugfix'
+      - 'bug'      
+change-template: '- $TITLE (#$NUMBER)'
+version-resolver:
+  major:
+    labels:
+      - 'major'
+  minor:
+    labels:
+      - 'minor'
+  patch:
+    labels:
+      - 'patch'
+  default: minor
+template: |
+  ## In This Release
+  $CHANGES

.github/workflows/release-drafter.yml

@@ -0,0 +1,18 @@
+name: Release Drafter
+
+on:
+  push:
+    # branches to consider in the event; optional, defaults to all
+    branches:
+      - master
+
+jobs:
+  update_release_draft:
+    runs-on: ubuntu-latest
+    steps:
+      # Drafts your next Release notes as Pull Requests are merged into "master"
+      - uses: release-drafter/release-drafter@v5
+        with:
+         config-name: release-drafter.yml         
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

PR_REVIEW.md

@@ -1,13 +1,26 @@
 ## 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.
 
+### Running Tests and Verifying Integrations
+
+General gulp commands include separate commands for serving the codebase on a built in webserver, creating code coverage reports and allowing serving integration examples. The `review-start` gulp command combinese those into one command.
+
+- Run `gulp review-start`, adding the host parameter `gulp review-start --host=0.0.0.0` will bind to all IPs on the machine
+    - A page will open which provides a hub for common reviewer tools.
+    - If you need to manually access the tools:
+        - Navigate to build/coverage/lcov-report/index.html to view coverage
+        - Navigate to integrationExamples/gpt/hellow_world.html for basic integration testing
+        - The hello_world.html and other examples can be edited and used as needed to verify functionality
+
 ### General PR review Process
+
 - All required global and bidder-adapter rules defined in the [Module Rules](https://docs.prebid.org/dev-docs/module-rules.html) must be followed. Please review these rules often - we depend on reviewers to enforce them.
-- Checkout the branch (these instructions are available on the github PR page as well).
+- 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 doesn't have enough unit test coverage, require that additional unit tests to be included in the PR.
 - Verify tests are green in Travis-ci + local build by running `gulp serve` | `gulp test`
@@ -18,12 +31,20 @@ For modules and core platform updates, the initial reviewer should request an ad
 - 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, if the change is in PBS-core or is an important module like the prebidServerBidAdapter, request 1 additional core member to review.
 - Once there are 2 `LGTM` on the PR, merge to master
-- 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)
+- The [draft release](https://github.com/prebid/Prebid.js/releases) notes are managed by [release drafter](https://github.com/release-drafter/release-drafter). To get the PR added to the release notes do the steps below. A GitHub action will use that information to build the release notes.
+    - Adjust the PR Title to be appropriate for release notes
+    - Add a label for `feature`, `maintenance`, `fix`, `bugfix` or `bug` to categorize the PR
+    - Add a SemVer label of `major`, `minor` or `patch` to indicate the scope of change    
 
 ### Reviewing a New or Updated Bid Adapter
-Documentation they're supposed to be following is https://docs.prebid.org/dev-docs/bidder-adaptor.html
+
+Documentation: https://docs.prebid.org/dev-docs/bidder-adaptor.html
 
 Follow steps above for general review process. In addition, please verify the following:
+- Verify the biddercode and aliases are valid:
+    - Lower case alphanumeric with the only special character allowed is underscore.
+    - The bidder code should be unique for the first 6 characters
+    - Reserved words that cannot be used as bidder names: all, context, data, general, prebid, and skadn
 - 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 code re-use is being done properly and that changes introduced by a bidder don't impact other bidders.
@@ -49,14 +70,16 @@ Follow steps above for general review process. In addition, please verify the fo
 - 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.
 
 ### Reviewing a New or Updated Analytics Adapter
-Documentation they're supposed to be following is https://docs.prebid.org/dev-docs/integrate-with-the-prebid-analytics-api.html
+
+Documentation: https://docs.prebid.org/dev-docs/integrate-with-the-prebid-analytics-api.html
 
 No additional steps above the general review process and making sure it conforms to the [Module Rules](https://docs.prebid.org/dev-docs/module-rules.html).
 
 Make sure there's a docs pull request
 
 ### Reviewing a New or Updated User ID Sub-Module
-Documentation they're supposed to be following is https://docs.prebid.org/dev-docs/modules/userId.html#id-providers
+
+Documentation: https://docs.prebid.org/dev-docs/modules/userId.html#id-providers
 
 Follow steps above for general review process. In addition:
 - Try running the new user ID module with a basic config and confirm it hits the endpoint and stores the results.
@@ -84,9 +107,11 @@ Follow steps above for general review process. In addition:
 - make sure there's a docs pull request
 
 ### Reviewing a New or Updated Real-Time-Data Sub-Module
-Documentation they're supposed to be following is https://docs.prebid.org/dev-docs/add-rtd-submodule.html
+
+Documentation: https://docs.prebid.org/dev-docs/add-rtd-submodule.html
 
 Follow steps above for general review process. In addition:
+
 - The RTD Provider must include a `providerRtdProvider.md` file. This file must have example parameters and document a sense of what to expect: what should change in the bidrequest, or what targeting data should be added?
 - Try running the new sub-module and confirm the provided test parameters.
 - Confirm that the module
@@ -100,9 +125,7 @@ Follow steps above for general review process. In addition:
 
 ## Ticket Coordinator
 
-Each week, Prebid Org assigns one person to keep an eye on incoming issues and PRs. Every Monday morning a reminder is
-sent to the prebid-js slack channel with a link to the spreadsheet. If you're on rotation, please check that list each
-Monday to see if you're on-duty.
+Each week, Prebid Org assigns one person to keep an eye on incoming issues and PRs. Every Monday morning a reminder is sent to the prebid-js slack channel with a link to the spreadsheet. If you're on rotation, please check that list each Monday to see if you're on-duty.
 
 When on-duty:
 - 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. 

README.md

@@ -93,12 +93,12 @@ Or for Babel 6:
 Then you can use Prebid.js as any other npm depedendency
 
 ```javascript
-import prebid from 'prebid.js';
+import pbjs from 'prebid.js';
 import 'prebid.js/modules/rubiconBidAdapter'; // imported modules will register themselves automatically with prebid
 import 'prebid.js/modules/appnexusBidAdapter';
-prebid.processQueue();  // required to process existing pbjs.queue blocks and setup any further pbjs.queue execution
+pbjs.processQueue();  // required to process existing pbjs.queue blocks and setup any further pbjs.queue execution
 
-prebid.requestBids({
+pbjs.requestBids({
   ...
 })
 
@@ -112,11 +112,11 @@ prebid.requestBids({
 
     $ git clone https://github.com/prebid/Prebid.js.git
     $ cd Prebid.js
-    $ npm install
+    $ npm ci
 
 *Note:* You need to have `NodeJS` 12.16.1 or greater installed.
 
-*Note:* In the 1.24.0 release of Prebid.js we have transitioned to using gulp 4.0 from using gulp 3.9.1.  To comply with gulp's recommended setup for 4.0, you'll need to have `gulp-cli` installed globally prior to running the general `npm install`.  This shouldn't impact any other projects you may work on that use an earlier version of gulp in its setup.
+*Note:* In the 1.24.0 release of Prebid.js we have transitioned to using gulp 4.0 from using gulp 3.9.1.  To comply with gulp's recommended setup for 4.0, you'll need to have `gulp-cli` installed globally prior to running the general `npm ci`.  This shouldn't impact any other projects you may work on that use an earlier version of gulp in its setup.
 
 If you have a previous version of `gulp` installed globally, you'll need to remove it before installing `gulp-cli`.  You can check if this is installed by running `gulp -v` and seeing the version that's listed in the `CLI` field of the output.  If you have the `gulp` package installed globally, it's likely the same version that you'll see in the `Local` field.  If you already have `gulp-cli` installed, it should be a lower major version (it's at version `2.0.1` at the time of the transition).
 
@@ -202,6 +202,11 @@ To run the unit tests:
 gulp test
 ```
 
+To run the unit tests for a particular file (example for pubmaticBidAdapter_spec.js):
+```bash
+gulp test --file "test/spec/modules/pubmaticBidAdapter_spec.js"
+```
+
 To generate and view the code coverage reports:
 
 ```bash
@@ -260,7 +265,7 @@ directory you will have sourcemaps available in your browser's developer tools.
 
 To run the example file, go to:
 
-+ `http://localhost:9999/integrationExamples/gpt/pbjs_example_gpt.html`
++ `http://localhost:9999/integrationExamples/gpt/hello_world.html`
 
 As you make code changes, the bundles will be rebuilt and the page reloaded automatically.
 

RELEASE_SCHEDULE.md

@@ -1,6 +1,14 @@
 **Table of Contents**
 - [Release Schedule](#release-schedule)
 - [Release Process](#release-process)
+  - [1. Make sure that all PRs have been named and labeled properly per the PR Process](#1-make-sure-that-all-prs-have-been-named-and-labeled-properly-per-the-pr-process)
+  - [2. Make sure all browserstack tests are passing](#2-make-sure-all-browserstack-tests-are-passing)
+  - [3. Prepare Prebid Code](#3-prepare-prebid-code)
+  - [4. Verify the Release](#4-verify-the-release)
+  - [5. Create a GitHub release](#5-create-a-github-release)
+  - [6. Update coveralls _(skip for legacy)_](#6-update-coveralls-skip-for-legacy)
+  - [7. Distribute the code](#7-distribute-the-code)
+  - [8. Increment Version for Next Release](#8-increment-version-for-next-release)
 - [Beta Releases](#beta-releases)
 - [FAQs](#faqs)
 
@@ -9,7 +17,7 @@
 We aim to push a new release of Prebid.js every week on Tuesday.
 
 While the releases will be available immediately for those using direct Git access,
-it will be about a week before the Prebid Org [Download Page](http://prebid.org/download.html) will be updated.  
+it will be about a week before the Prebid Org [Download Page](http://prebid.org/download.html) will be updated.
 
 You can determine what is in a given build using the [releases page](https://github.com/prebid/Prebid.js/releases)
 
@@ -19,14 +27,20 @@ Announcements regarding releases will be made to the #headerbidding-dev channel
 
 _Note: If `github.com/prebid/Prebid.js` is not configured as the git origin for your repo, all of the following git commands will have to be modified to reference the proper remote (e.g. `upstream`)_
 
-1. Make Sure all browserstack tests are passing. On PR merge to master CircleCI will run unit tests on browserstack. Checking the last CircleCI build [here](https://circleci.com/gh/prebid/Prebid.js) for master branch will show you detailed results. 
-
-   In case of failure do following, 
+### 1. Make sure that all PRs have been named and labeled properly per the [PR Process](https://github.com/prebid/Prebid.js/blob/master/PR_REVIEW.md#general-pr-review-process)
+   * Do this by checking the latest draft release from the [releases page](https://github.com/prebid/Prebid.js/releases) and make sure nothing appears in the first section called "In This Release". If they do, please open the PRs and add the appropriate labels.
+   * Do a quick check that all the titles/descriptions look ok, and if not, adjust the PR title.
+
+### 2. Make sure all browserstack tests are passing
+
+   On PR merge to master, CircleCI will run unit tests on browserstack. Checking the last CircleCI build [here](https://circleci.com/gh/prebid/Prebid.js) for master branch will show you detailed results.**
+
+   In case of failure do following,
      - Try to fix the failing tests.
      - If you are not able to fix tests in time. Skip the test, create issue and tag contributor.
 
-   #### How to run tests in browserstack
-   
+   **How to run tests in browserstack**
+
    _Note: the following browserstack information is only relevant for debugging purposes, if you will not be debugging then it can be skipped._
 
    Set the environment variables. You may want to add these to your `~/.bashrc` for convenience.
@@ -35,40 +49,40 @@ _Note: If `github.com/prebid/Prebid.js` is not configured as the git origin for
    export BROWSERSTACK_USERNAME="my browserstack username"
    export BROWSERSTACK_ACCESS_KEY="my browserstack access key"
    ```
-   
+
    ```
    gulp test --browserstack >> prebid_test.log
-   
+
    vim prebid_test.log // Will show the test results
    ```
 
 
-2. Prepare Prebid Code
+### 3. Prepare Prebid Code
 
    Update the package.json version to become the current release. Then commit your changes.
 
    ```
-   git commit -m "Prebid 1.x.x Release"
+   git commit -m "Prebid 4.x.x Release"
    git push
    ```
 
-3. Verify Release
+### 4. Verify the Release
 
    Make sure your there are no more merges to master branch. Prebid code is clean and up to date.
 
-4. Create a GitHub release
+### 5. Create a GitHub release
+
+   Edit the most recent [release notes](https://github.com/prebid/Prebid.js/releases) draft and make sure the correct version is set and the master branch is selected in the dropdown. Click `Publish release`. GitHub will create release tag.
 
-   Edit the most recent [release notes](https://github.com/prebid/Prebid.js/releases) draft and make sure the correct tag is in the dropdown. Click `Publish`. GitHub will create release tag. 
-
-   Pull these changes locally by running command 
+   Pull these changes locally by running command
    ```
    git pull
    git fetch --tags
-   ``` 
-   
+   ```
+
    and verify the tag.
 
-5. Update coveralls _(skip for legacy)_
+### 6. Update coveralls _(skip for legacy)_
 
    We use https://coveralls.io/ to show parts of code covered by unit tests.
 
@@ -80,35 +94,23 @@ _Note: If `github.com/prebid/Prebid.js` is not configured as the git origin for
 
    Run `gulp coveralls` to update code coverage history.
 
-6. Distribute the code 
+### 7. Distribute the code
 
-   _Note: do not go to step 7 until step 6 has been verified completed._
+   _Note: do not go to step 8 until step 7 has been verified completed._
 
    Reach out to any of the Appnexus folks to trigger the jenkins job.
 
-   // TODO 
+   // TODO:
    Jenkins job is moving files to appnexus cdn, pushing prebid.js to npm, purging cache and sending notification to slack.
    Move all the files from Appnexus CDN to jsDelivr and create bash script to do above tasks.
 
-7. Post Release Version
-
-   Update the version
-   Manually edit Prebid's package.json to become "1.x.x-pre" (using the values for the next release). Then commit your changes.
+### 8. Increment Version for Next Release
+
+   Update the version by manually editing Prebid's `package.json` to become "4.x.x-pre" (using the values for the next release). Then commit your changes.
    ```
    git commit -m "Increment pre version"
    git push
    ```
-
-8. Create new release draft
-
-   Go to [github releases](https://github.com/prebid/Prebid.js/releases) and add a new draft for the next version of Prebid.js with the following template:
-```
-## 🚀New Features
- 
-## 🛠Maintenance
- 
-## 🐛Bug Fixes
-```
 
 ## Beta Releases
 
@@ -129,11 +131,8 @@ Characteristics of a `GA` release:
 ## FAQs
 
 **1. Is there flexibility in the schedule?**
-
-If a major bug is found in the current release, a maintenance patch will be done as soon as possible.
-
-It is unlikely that we will put out a maintenance patch at the request of a given bid adapter or module owner.
+* If a major bug is found in the current release, a maintenance patch will be done as soon as possible.
+* It is unlikely that we will put out a maintenance patch at the request of a given bid adapter or module owner.
 
 **2. What Pull Requests make it into a release?**
-
-Every PR that's merged into master will be part of a release. Here are the [PR review guidelines](https://github.com/prebid/Prebid.js/blob/master/PR_REVIEW.md).
+* Every PR that's merged into master will be part of a release. Here are the [PR review guidelines](https://github.com/prebid/Prebid.js/blob/master/PR_REVIEW.md).

allowedModules.js

@@ -12,7 +12,6 @@ module.exports = {
   'modules': [
     ...sharedWhiteList,
     'criteo-direct-rsa-validate',
-    'jsencrypt',
     'crypto-js',
     'live-connect' // Maintained by LiveIntent : https://github.com/liveintent-berlin/live-connect/
   ],