diff --git a/.babelrc.js b/.babelrc.js
index bece57ec4a5..2fa95d0716e 100644
--- a/.babelrc.js
+++ b/.babelrc.js
@@ -20,7 +20,7 @@ module.exports = {
"safari >=8",
"edge >= 14",
"ff >= 57",
- "ie >= 10",
+ "ie >= 11",
"ios >= 8"
]
}
diff --git a/.circleci/config.yml b/.circleci/config.yml
index 5ea5e87218c..ea5fb916a91 100644
--- a/.circleci/config.yml
+++ b/.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
\ No newline at end of file
+ pipelines: true
diff --git a/.eslintrc.js b/.eslintrc.js
index c64ab379c52..3a3210cec67 100644
--- a/.eslintrc.js
+++ b/.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.
diff --git a/.github/release-drafter.yml b/.github/release-drafter.yml
new file mode 100644
index 00000000000..a3246cffd6d
--- /dev/null
+++ b/.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
diff --git a/.github/workflows/release-drafter.yml b/.github/workflows/release-drafter.yml
new file mode 100644
index 00000000000..8152b61275d
--- /dev/null
+++ b/.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 }}
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 016f4055216..606d26cd25a 100644
--- a/CONTRIBUTING.md
+++ b/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:
diff --git a/PR_REVIEW.md b/PR_REVIEW.md
index dac50593d6e..84131c177a3 100644
--- a/PR_REVIEW.md
+++ b/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
diff --git a/README.md b/README.md
index 0dd5b25a50f..a220dd69f66 100644
--- a/README.md
+++ b/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)
@@ -91,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({
...
})
@@ -110,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).
@@ -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.
@@ -200,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
@@ -258,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.
@@ -266,7 +273,7 @@ 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).
@@ -274,9 +281,7 @@ Our PR review process can be found [here](https://github.com/prebid/Prebid.js/tr
### 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
diff --git a/RELEASE_SCHEDULE.md b/RELEASE_SCHEDULE.md
index 7b2c6244bd7..bfbd0772c3e 100644
--- a/RELEASE_SCHEDULE.md
+++ b/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).
diff --git a/allowedModules.js b/allowedModules.js
index 2a521f781f9..2d23b35c501 100644
--- a/allowedModules.js
+++ b/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/
],
@@ -21,7 +20,6 @@ module.exports = {
'fun-hooks/no-eval',
'just-clone',
'dlv',
- 'dset',
- 'deep-equal'
+ 'dset'
]
};
diff --git a/browsers.json b/browsers.json
index 91e0548d78a..f73bbbb8aac 100644
--- a/browsers.json
+++ b/browsers.json
@@ -23,11 +23,11 @@
"device": null,
"os": "Windows"
},
- "bs_chrome_80_windows_10": {
+ "bs_chrome_89_windows_10": {
"base": "BrowserStack",
"os_version": "10",
"browser": "chrome",
- "browser_version": "80.0",
+ "browser_version": "89.0",
"device": null,
"os": "Windows"
},
diff --git a/gulpfile.js b/gulpfile.js
index e9c0f3ebd05..1386fa63e5e 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -30,7 +30,7 @@ const execa = require('execa');
var prebid = require('./package.json');
var dateString = 'Updated : ' + (new Date()).toISOString().substring(0, 10);
-var banner = '/* <%= prebid.name %> v<%= prebid.version %>\n' + dateString + ' */\n';
+var banner = '/* <%= prebid.name %> v<%= prebid.version %>\n' + dateString + '*/\n';
var port = 9999;
console.timeEnd('Loading Plugins in Prebid');
const FAKE_SERVER_HOST = argv.host ? argv.host : 'localhost';
@@ -95,7 +95,8 @@ function viewCoverage(done) {
connect.server({
port: coveragePort,
root: 'build/coverage/lcov-report',
- livereload: false
+ livereload: false,
+ debug: true
});
opens('http://' + mylocalhost + ':' + coveragePort);
done();
@@ -103,6 +104,19 @@ function viewCoverage(done) {
viewCoverage.displayName = 'view-coverage';
+// View the reviewer tools page
+function viewReview(done) {
+ var mylocalhost = (argv.host) ? argv.host : 'localhost';
+ var reviewUrl = 'http://' + mylocalhost + ':' + port + '/integrationExamples/reviewerTools/index.html'; // reuse the main port from 9999
+
+ // console.log(`stdout: opening` + reviewUrl);
+
+ opens(reviewUrl);
+ done();
+};
+
+viewReview.displayName = 'view-review';
+
// Watch Task with Live Reload
function watch(done) {
var connect = require('gulp-connect');
@@ -121,6 +135,7 @@ function watch(done) {
connect.server({
https: argv.https,
port: port,
+ host: FAKE_SERVER_HOST,
root: './',
livereload: true
});
@@ -130,6 +145,12 @@ function watch(done) {
done();
};
+function makeModuleList(modules) {
+ return modules.map(module => {
+ return '"' + module + '"'
+ });
+}
+
function makeDevpackPkg() {
var _ = require('lodash');
var connect = require('gulp-connect');
@@ -148,6 +169,7 @@ function makeDevpackPkg() {
return gulp.src([].concat(moduleSources, analyticsSources, 'src/prebid.js'))
.pipe(helpers.nameModules(externalModules))
.pipe(webpackStream(cloned, webpack))
+ .pipe(replace(/('|")v\$prebid\.modulesList\$('|")/g, makeModuleList(externalModules)))
.pipe(gulp.dest('build/dev'))
.pipe(connect.reload());
}
@@ -174,10 +196,15 @@ function makeWebpackPkg() {
.pipe(helpers.nameModules(externalModules))
.pipe(webpackStream(cloned, webpack))
.pipe(uglify())
+ .pipe(replace(/('|")v\$prebid\.modulesList\$('|")/g, makeModuleList(externalModules)))
.pipe(gulpif(file => file.basename === 'prebid-core.js', header(banner, { prebid: prebid })))
.pipe(gulp.dest('build/dist'));
}
+function getModulesListToAddInBanner(modules) {
+ return (modules.length > 0) ? modules.join(', ') : 'All available modules in current version.';
+}
+
function gulpBundle(dev) {
return bundle(dev).pipe(gulp.dest('build/' + (dev ? 'dev' : 'dist')));
}
@@ -238,6 +265,8 @@ function bundle(dev, moduleArr) {
return gulp.src(
entries
)
+ // Need to uodate the "Modules: ..." section in comment with the current modules list
+ .pipe(replace(/(Modules: )(.*?)(\*\/)/, ('$1' + getModulesListToAddInBanner(helpers.getArgModules()) + ' $3')))
.pipe(gulpif(dev, sourcemaps.init({ loadMaps: true })))
.pipe(concat(outputFileName))
.pipe(gulpif(!argv.manualEnable, footer('\n<%= global %>.processQueue();', {
@@ -306,7 +335,7 @@ function test(done) {
} else {
var karmaConf = karmaConfMaker(false, argv.browserstack, argv.watch, argv.file);
- var browserOverride = helpers.parseBrowserArgs(argv).map(helpers.toCapitalCase);
+ var browserOverride = helpers.parseBrowserArgs(argv);
if (browserOverride.length > 0) {
karmaConf.browsers = browserOverride;
}
@@ -433,4 +462,8 @@ gulp.task('e2e-test', gulp.series(clean, setupE2e, gulp.parallel('build-bundle-p
gulp.task(bundleToStdout);
gulp.task('bundle', gulpBundle.bind(null, false)); // used for just concatenating pre-built files with no build step
+// build task for reviewers, runs test-coverage, serves, without watching
+gulp.task(viewReview);
+gulp.task('review-start', gulp.series(clean, lint, gulp.parallel('build-bundle-dev', watch, testCoverage), viewReview));
+
module.exports = nodeBundle;
diff --git a/integrationExamples/gpt/adUnitFloors.html b/integrationExamples/gpt/adUnitFloors.html
new file mode 100644
index 00000000000..bb48a20ef78
--- /dev/null
+++ b/integrationExamples/gpt/adUnitFloors.html
@@ -0,0 +1,112 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Prebid.js Test
+ Div-1
+
+
+
+
+
+
+
diff --git a/integrationExamples/gpt/adloox.html b/integrationExamples/gpt/adloox.html
new file mode 100644
index 00000000000..33f8b9be6a2
--- /dev/null
+++ b/integrationExamples/gpt/adloox.html
@@ -0,0 +1,211 @@
+
+
+
+ Prebid Display/Video Merged Auction with Adloox Integration
+
+
+
+
+
+
+
+
+ Prebid Display/Video Merged Auction with Adloox Integration
+
+ div-1
+
+
+
+
+ div-2
+
+
+
+
+ video-1
+
+
+
+
+
diff --git a/integrationExamples/gpt/audigentSegments_example.html b/integrationExamples/gpt/audigentSegments_example.html
deleted file mode 100644
index 7739b558327..00000000000
--- a/integrationExamples/gpt/audigentSegments_example.html
+++ /dev/null
@@ -1,257 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Audigent Segments Prebid
-
-
-
-
-TDID:
-
-
-
-Audigent Segments:
-
-
-
-
diff --git a/integrationExamples/gpt/creative_rendering.html b/integrationExamples/gpt/creative_rendering.html
index aef8b7f1654..04d4736c631 100644
--- a/integrationExamples/gpt/creative_rendering.html
+++ b/integrationExamples/gpt/creative_rendering.html
@@ -1,9 +1,4 @@
-
-
-
-
+
-
-
-
-
-
-
-
-
-
-
-
-
- DigiTrust Prebid Full Sample
-
-
-
- This sample shows the simplest integration path for using DigiTrust ID with Prebid.
- You can use DigiTrust ID without integrating the entire DigiTrust suite.
-
-
-
-
-
-
-
-
-
-
-