Merge pull request #1 from prebid/master

Merge with base

.circleci/config.yml

@@ -7,8 +7,8 @@ aliases:
   - &environment
       docker:
         # specify the version you desire here
-        - image: circleci/node:8.9.0
-        
+        - 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

.nvmrc

@@ -1 +1 @@
-8.9
+12.16.1

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

@@ -6,44 +6,98 @@ 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.
 
 ### 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):
-    - Add support for GDPR consentManagement module > add `gdpr_supported: true`
-    - Add support for US Privacy consentManagement module > add `usp_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`
-    - Add support for SChain > add `schain_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.
+- 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)
-- 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:
+### 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 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.
+- 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`
+    - If they support one or more userId modules, add `userId: (list of supported vendors)`
+    - If they support video and/or native mediaTypes add `media_types: video, native`. Note that display is added by default. If you don't support display, add "no-display" as the first entry, e.g. `media_types: no-display, native`
+    - 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 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

README.md

@@ -14,6 +14,8 @@ This README is for developers who want to contribute to Prebid.js.
 Additional documentation can be found at [the Prebid homepage](http://prebid.org).
 Working examples can be found in [the developer docs](http://prebid.org/dev-docs/getting-started.html).
 
+Prebid.js is open source software that is offered for free as a convenience. While it is designed to help companies address legal requirements associated with header bidding, we cannot and do not warrant that your use of Prebid.js will satisfy legal requirements. You are solely responsible for ensuring that your use of Prebid.js complies with all applicable laws.  We strongly encourage you to obtain legal advice when using Prebid.js to ensure your implementation complies with all laws where you operate.
+
 **Table of Contents**
 
 - [Usage](#Usage)
@@ -112,7 +114,7 @@ prebid.requestBids({
     $ cd Prebid.js
     $ npm install
 
-*Note:* You need to have `NodeJS` 8.9.x or greater installed.
+*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.
 
@@ -140,7 +142,7 @@ This runs some code quality checks, starts a web server at `http://localhost:999
 
 ### Build Optimization
 
-The standard build output contains all the available modules from within the `modules` folder.
+The standard build output contains all the available modules from within the `modules` folder.  Note, however that there are bid adapters which support multiple bidders through aliases, so if you don't see a file in modules for a bid adapter, you may need to grep the repository to find the name of the module you need to include.
 
 You might want to exclude some/most of them from the final bundle.  To make sure the build only includes the modules you want, you can specify the modules to be included with the `--modules` CLI argument.
 
@@ -266,17 +268,15 @@ As you make code changes, the bundles will be rebuilt and the page reloaded auto
 
 ## Contribute
 
-Many SSPs, bidders, and publishers have contributed to this project. [60+ Bidders](https://github.com/prebid/Prebid.js/tree/master/src/adapters) are supported by Prebid.js.
+Many SSPs, bidders, and publishers have contributed to this project. [Hundreds of bidders](https://github.com/prebid/Prebid.js/tree/master/src/adapters) are supported by Prebid.js.
 
 For guidelines, see [Contributing](./CONTRIBUTING.md).
 
 Our PR review process can be found [here](https://github.com/prebid/Prebid.js/tree/master/PR_REVIEW.md).
 
 ### Add a Bidder Adapter
 
-To add a bidder adapter module, see the instructions in [How to add a bidder adaptor](http://prebid.org/dev-docs/bidder-adaptor.html).
-
-Please **do NOT load Prebid.js inside your adapter**. If you do this, we will reject or remove your adapter as appropriate.
+To add a bidder adapter module, see the instructions in [How to add a bidder adapter](https://docs.prebid.org/dev-docs/bidder-adaptor.html).
 
 ### Code Quality
 

allowedModules.js

@@ -21,7 +21,6 @@ module.exports = {
     'fun-hooks/no-eval',
     'just-clone',
     'dlv',
-    'dset',
-    'deep-equal'
+    'dset'
   ]
 };