Stable release for v4.43

.babelrc.js

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

.circleci/config.yml

@@ -8,7 +8,7 @@ aliases:
       docker:
         # specify the version you desire here
         - image: circleci/node:12.16.1
-        
+      resource_class: xlarge
         # Specify service dependencies here if necessary
         # CircleCI maintains a library of pre-built images
         # documented at https://circleci.com/docs/2.0/circleci-images/
@@ -94,4 +94,4 @@ workflows:
       - e2etest
 
 experimental:
-  pipelines: true
+  pipelines: true

.eslintrc.js

@@ -28,7 +28,6 @@ module.exports = {
     "comma-dangle": "off",
     "semi": "off",
     "space-before-function-paren": "off",
-    "import/extensions": ["error", "ignorePackages"],
 
     // Exceptions below this line are temporary, so that eslint can be added into the CI process.
     // Violations of these styles should be fixed, and the exceptions removed over time.

.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 }}

CONTRIBUTING.md

@@ -3,9 +3,11 @@ Contributions are always welcome. To contribute, [fork](https://help.github.com/
 commit your changes, and [open a pull request](https://help.github.com/articles/using-pull-requests/) against the
 master branch.
 
-Pull requests must have 80% code coverage before beign considered for merge.
+Pull requests must have 80% code coverage before being considered for merge.
 Additional details about the process can be found [here](./PR_REVIEW.md).
 
+There are more details available if you'd like to contribute a [bid adapter](https://docs.prebid.org/dev-docs/bidder-adaptor.html) or [analytics adapter](https://docs.prebid.org/dev-docs/integrate-with-the-prebid-analytics-api.html).
+
 ## Issues
 [prebid.org](http://prebid.org/) contains documentation that may help answer questions you have about using Prebid.js.
 If you can't find the answer there, try searching for a similar issue on the [issues page](https://github.com/prebid/Prebid.js/issues).
@@ -57,7 +59,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/modules`
+- Tests for bidder adapters are located in `test/spec/modules`
 
 A test module might have the following general structure:
 

PR_REVIEW.md

@@ -5,16 +5,55 @@ If the PR is for a standard bid adapter or a standard analytics adapter, just th
 
 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 acceess 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 exampls 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).
 - 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 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`
 - Verify no code quality violations are present from linting (should be reported in terminal)
+- Make sure the code is not setting cookies or localstorage directly -- it must use the `StorageManager`.
 - 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):
+- 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
+- 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
+
+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.
+- If the adapter being submitted is an alias type, check with the bidder contact that is being aliased to make sure it's allowed.
+- All bidder parameter conventions must be followed:
+    - Video params must be read from AdUnit.mediaTypes.video when available; however bidder config can override the ad unit. 
+    - First party data must be read from [`fpd.context` and `fpd.user`](https://docs.prebid.org/dev-docs/publisher-api-reference.html#setConfig-fpd).
+    - Adapters that accept a floor parameter must also support the [floors module](https://docs.prebid.org/dev-docs/modules/floors.html) -- look for a call to the `getFloor()` function.
+    - Adapters cannot accept an schain parameter. Rather, they must look for the schain parameter at bidRequest.schain.
+    - The bidRequest page referrer must checked in addition to any bidder-specific parameter.
+    - If they're getting the COPPA flag, it must come from config.getConfig('coppa');
+- Below are some examples of bidder specific updates that should require docs update (in their dev-docs/bidders/BIDDER.md file):
     - If they support the GDPR consentManagement module and TCF1, add `gdpr_supported: true`
     - If they support the GDPR consentManagement module and TCF2, add `tcf2_supported: true`
     - If they support the US Privacy consentManagementUsp module, add `usp_supported: true`
@@ -23,30 +62,60 @@ For modules and core platform updates, the initial reviewer should request an ad
     - If they support COPPA, add `coppa_supported: true`
     - If they support SChain, add `schain_supported: true`
     - If their bidder doesn't work well with safeframed creatives, add `safeframes_ok: false`. This will alert publishers to not use safeframed creatives when creating the ad server entries for their bidder.
-    - If they're a member of Prebid.org, add `prebid_member: 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:
-- 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.
+    - If they're setting a deal ID in some scenarios, add `bidder_supports_deals: true`
+    - If they have an IAB Global Vendor List ID, add `gvl_id: ID`. There's no default.
 - 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
+
+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
+
+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.
+- the filename should be camel case ending with `IdSystem` (e.g. `myCompanyIdSystem.js`)
+- the `const MODULE_NAME` value should be camel case ending with `Id` (e.g. `myCompanyId` )
+- the response of the `decode` method should be an object with the key being ideally camel case similar to the module name and ending in `id` or `Id`, but in some cases this value is a shortened name and sometimes with the `id` part being all lowercase, provided there are no other uppercase letters. if there's no id or it's an invalid object, the response should be `undefined`. example "valid" values (although this is more style than a requirement)
+   - `mcid`
+   - `mcId`
+   - `myCompanyId`
+- make sure they've added references of their new module everywhere required:
+  - modules/.submodules.json
+  - modules/userId/eids.js
+  - modules/userId/eids.md
+  - modules/userId/userId.md
+- tests can go either within the userId_spec.js file or in their own _spec file if they wish
+- GVLID is recommended in the *IdSystem file if they operate in EU
+- make sure example configurations align to the actual code (some modules use the userId storage settings and allow pub configuration, while others handle reading/writing cookies on their own, so should not include the storage params in examples)
+- the 3 available methods (getId, extendId, decode) should be used as they were intended
+  - decode (required method) should not be making requests to retrieve a new ID, it should just be decoding a response
+  - extendId (optional method) should not be making requests to retrieve a new ID, it should just be adding additional data to the id object
+  - getId (required method) should be the only method that gets a new ID (from ajax calls or a cookie/local storage). this ensures that decode and extend do not unnecessarily delay the auction in places where it is not expected.
+- in the eids.js file, the source should be the actual domain of the provider, not a made up domain.
+- in the eids.js file, the key in the array should be the same value as the key in the decode function
+- make sure all supported config params align in the submodule js file and the docs / examples
+- 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
+
+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
+  - is not loading external code. If it is, escalate to the #prebid-js Slack channel. 
+  - is reading `config` from the function signature rather than calling `getConfig`.
+  - is sending data to the bid request only as either First Party Data or in bidRequest.rtd.RTDPROVIDERCODE.
+  - is making HTTPS requests as early as possible, but not more often than needed.
+  - doesn't force bid adapters to load additional code.
+- Consider whether the kind of data the module is obtaining could have privacy implications. If so, make sure they're utilizing the `consent` data passed to them.
+- Make sure there's a docs pull request
+
 ## Ticket Coordinator
 
 Each week, Prebid Org assigns one person to keep an eye on incoming issues and PRs. Every Monday morning a reminder is