backport(v3.2.x) onto the v3.x branch

.github/pull-request-template.md

@@ -1,12 +1,12 @@
 <!-- General PR guidelines:
 
-Most PRs should be opened against the master branch.
+Most PRs should be opened against the main branch.
 
  -->
 
 ## Proposed Changes
 
-- 
+-
 -
 -
 

.github/workflows/nodejs-ci-action.yml

@@ -5,9 +5,9 @@ name: Node.js CI
 
 on:
   push:
-    branches: [ master ]
+    branches: [ main ]
   pull_request:
-    branches: [ master ]
+    branches: [ main ]
 
 jobs:
   build:

.gitignore

@@ -12,6 +12,7 @@ index.js
 /browser
 /bundles
 /dist
+/docs
 
 # Runtime data
 pids

CONTRIBUTING.md

@@ -38,4 +38,4 @@ check your code style for linting errors without running tests, you can just
 run `npm run lint`. If there are errors, you can usually fix them automatically
 by running `npm run fix`.
 
-Linting rules are declared in [.eslintrc](https://github.com/cloudevents/sdk-javascript/blob/master/.eslintrc).
+Linting rules are declared in [.eslintrc](https://github.com/cloudevents/sdk-javascript/blob/main/.eslintrc).

README.md

@@ -29,8 +29,8 @@ npm install cloudevents
 
 #### Receiving Events
 
-You can choose almost any popular web framework for port binding. Use an
-`HTTPReceiver` to process the incoming HTTP request. The receiver accepts
+You can choose almost any popular web framework for port binding. Use a
+`Receiver` to process the incoming HTTP request. The receiver accepts
 binary and structured events in either the 1.0 or 0.3 protocol formats.
 
 ```js
@@ -110,23 +110,23 @@ const ce2 = ce.cloneWith({extension: "Value"});
 ### Example Applications
 
 There are a few trivial example applications in
-[the examples folder](https://github.com/cloudevents/sdk-javascript/tree/master/examples).
+[the examples folder](https://github.com/cloudevents/sdk-javascript/tree/main/examples).
 There you will find Express.js, TypeScript and Websocket examples.
 
 ## Supported specification features
 
-| Core Specification |  [v0.3](v03spec) | [v1.0](v1spec) |
+| Core Specification |  [v0.3](https://github.com/cloudevents/spec/blob/v0.3/spec.md) | [v1.0](https://github.com/cloudevents/spec/blob/v1.0/spec.md) |
 | ----------------------------- | --- | --- |
 | CloudEvents Core              | :heavy_check_mark: | :heavy_check_mark: |
 ---
 
-| Event Formats |  [v0.3](v03spec) | [v1.0](v1spec) |
+| Event Formats |  [v0.3](https://github.com/cloudevents/spec/tree/v0.3) | [v1.0](https://github.com/cloudevents/spec/tree/v1.0) |
 | ----------------------------- | --- | --- |
 | AVRO Event Format             | :x: | :x: |
 | JSON Event Format             | :heavy_check_mark: | :heavy_check_mark: |
 ---
 
-| Transport Protocols |  [v0.3](v03spec) | [v1.0](v1spec) |
+| Transport Protocols |  [v0.3](https://github.com/cloudevents/spec/tree/v0.3) | [v1.0](https://github.com/cloudevents/spec/tree/v1.0) |
 | ----------------------------- | --- | --- |
 | AMQP Protocol Binding         | :x: | :x: |
 | HTTP Protocol Binding         | :heavy_check_mark: | :heavy_check_mark: |
@@ -150,8 +150,16 @@ There you will find Express.js, TypeScript and Websocket examples.
 ## Contributing
 
 We love contributions from the community! Please check the
-[Contributor's Guide](https://github.com/cloudevents/sdk-javascript/blob/master/CONTRIBUTING.md)
+[Contributor's Guide](https://github.com/cloudevents/sdk-javascript/blob/main/CONTRIBUTING.md)
 for information on how to get involved.
 
-[v1spec]: https://github.com/cloudevents/spec/tree/v1.0
-[v103pec]: https://github.com/cloudevents/spec/tree/v0.3
+Each SDK may have its own unique processes, tooling and guidelines, common
+governance related material can be found in the
+[CloudEvents `community`](https://github.com/cloudevents/spec/tree/master/community)
+directory. In particular, in there you will find information concerning
+how SDK projects are
+[managed](https://github.com/cloudevents/spec/blob/master/community/SDK-GOVERNANCE.md),
+[guidelines](https://github.com/cloudevents/spec/blob/master/community/SDK-maintainer-guidelines.md)
+for how PR reviews and approval, and our
+[Code of Conduct](https://github.com/cloudevents/spec/blob/master/community/GOVERNANCE.md#additional-information)
+information.

RELEASE_GUIDELINES.md

@@ -6,15 +6,15 @@ To prepare for a new release, create a [new issue](https://github.com/cloudevent
 
 For example: "Proposal for 3.2.0 release", or something similar.  If you are not sure which version is the next version to be released, you can run `npm run release -- --dry-run` to find out what the next version will be.
 
-The body of the issue should be the commits that will be part of the release.  This can be easily accomplished by running a git log command with a defined **range**.  This range should start at the most recent version tag and end at the latest commit in the master branch.
+The body of the issue should be the commits that will be part of the release.  This can be easily accomplished by running a git log command with a defined **range**.  This range should start at the most recent version tag and end at the latest commit in the main branch.
 
 For example:
 
 ```
-git log v3.0.1..upstream/master --oneline
+git log v3.0.1..upstream/main --oneline
 ```
 
-This will output all the commits from the 3.0.1 tag to the latest commits in the remote upstream/master branch.
+This will output all the commits from the 3.0.1 tag to the latest commits in the remote upstream/main branch.
 
 This output should be pasted into the issue as normal text.  This will allow Github to magically turn all commit hashes and PR/Issues numbers to links.
 
@@ -37,7 +37,7 @@ npm run release
 This will update the CHANGELOG.md and create a new tag based on the version.  This can then be pushed upstream by doing:
 
 ```
-git push upstream master --follow-tags
+git push upstream main --follow-tags
 ```
 
 ### Create the release on GitHub

examples/express-ex/index.js

@@ -1,32 +1,27 @@
-/* eslint-disable no-console */
+/* eslint-disable */
 
 const express = require("express");
-const {Receiver} = require("cloudevents");
-
+const { Receiver } = require("cloudevents");
 const app = express();
-
-app.use((req, res, next) => {
-  let data = "";
-
-  req.setEncoding("utf8");
-  req.on("data", function (chunk) {
-    data += chunk;
-  });
-
-  req.on("end", function () {
-    req.body = data;
-    next();
-  });
-});
+const bodyParser = require('body-parser')
+app.use(bodyParser.json())
 
 app.post("/", (req, res) => {
   console.log("HEADERS", req.headers);
   console.log("BODY", req.body);
 
   try {
     const event = Receiver.accept(req.headers, req.body);
-    console.log(`Accepted event: ${event}`);
-    res.status(201).json(event);
+    // respond as an event
+    const responseEventMessage = new CloudEvent({
+      source: '/',
+      type: 'event:response',
+      ...event
+    });
+    responseEventMessage.data = {
+      hello: 'world'
+    };
+    res.status(201).json(responseEventMessage);
   } catch (err) {
     console.error(err);
     res.status(415).header("Content-Type", "application/json").send(JSON.stringify(err));

examples/express-ex/package.json

@@ -14,7 +14,8 @@
   "author": "fabiojose@gmail.com",
   "license": "Apache-2.0",
   "dependencies": {
-    "cloudevents": "~3.0.0",
+    "body-parser": "^1.19.0",
+    "cloudevents": "^3.1.0",
     "express": "^4.17.1"
   }
 }

examples/typescript-ex/package.json

@@ -28,6 +28,6 @@
     "typescript": "~3.9.5"
   },
   "dependencies": {
-    "cloudevents": "~3.0.1"
+    "cloudevents": "~3.1.0"
   }
 }

maintainer_guidelines.md

@@ -26,15 +26,15 @@ When landing pull requests, be sure to check the first line uses an appropriate
 
 ## Branch Management
 
-The `master` branch is the bleeding edge. New major versions of the module
+The `main` branch is the bleeding edge. New major versions of the module
 are cut from this branch and tagged. If you intend to submit a pull request
-you should use `master HEAD` as your starting point.
+you should use `main HEAD` as your starting point.
 
 Each major release will result in a new branch and tag. For example, the
 release of version 1.0.0 of the module will result in a `v1.0.0` tag on the
 release commit, and a new branch `v1.x.y` for subsequent minor and patch
 level releases of that major version. However, development will continue
-apace on `master` for the next major version - e.g. 2.0.0. Version branches
+apace on `main` for the next major version - e.g. 2.0.0. Version branches
 are only created for each major version. Minor and patch level releases
 are simply tagged.
 

package.json

@@ -6,7 +6,7 @@
   "scripts": {
     "watch": "tsc --project tsconfig.json --watch",
     "build": "tsc --project tsconfig.json && tsc --project tsconfig.browser.json && webpack",
-    "lint": "eslint 'src/**/*.{js,ts}' 'test/**/*.{js,ts}'",
+    "lint": "eslint 'src/**/*.{js,ts}' 'test/**/*.{js,ts}' cucumber.js",
     "lint:fix": "eslint 'src/**/*.{js,ts}' 'test/**/*.{js,ts}' --fix",
     "pretest": "npm run lint && npm run conformance",
     "test": "mocha --require ts-node/register ./test/integration/**/*.ts",
@@ -100,7 +100,7 @@
   "dependencies": {
     "ajv": "~6.12.3",
     "axios": "~0.19.2",
-    "uuid": "~8.2.0"
+    "uuid": "~8.3.0"
   },
   "devDependencies": {
     "@types/ajv": "^1.0.0",

pr_guidelines.md

@@ -5,13 +5,15 @@ a pull request in this repository. We hope it will help you have an easy time
 managing your work and a positive, satisfying experience when contributing
 your code. Thanks for getting involved! :rocket:
 
-* [Getting Started](#getting-started)
-* [Branches](#branches)
-* [Commit Messages](#commit-messages)
-* [Staying current with master](#staying-current-with-master)
-* [Style Guide](#style-guide)
-* [Submitting and Updating a Pull Request](#submitting-and-updating-a-pull-request)
-* [Congratulations!](#congratulations)
+- [Pull Request Guidelines](#pull-request-guidelines)
+  - [Getting Started](#getting-started)
+  - [Branches](#branches)
+  - [Commit Messages](#commit-messages)
+    - [Signing your commits](#signing-your-commits)
+  - [Staying Current with `main`](#staying-current-with-main)
+  - [Style Guide](#style-guide)
+  - [Submitting and Updating Your Pull Request](#submitting-and-updating-your-pull-request)
+  - [Congratulations!](#congratulations)
 
 ## Getting Started
 
@@ -35,7 +37,7 @@ you might create a branch named `48-fix-http-agent-error`.
 
 ```console
 git fetch upstream
-git reset --hard upstream/master
+git reset --hard upstream/main
 git checkout FETCH_HEAD
 git checkout -b 48-fix-http-agent-error
 ```
@@ -102,19 +104,19 @@ Date:   Thu Feb 2 11:41:15 2018 -0800
 Notice the `Author` and `Signed-off-by` lines match. If they don't your PR will
 be rejected by the automated DCO check.
 
-## Staying Current with `master`
+## Staying Current with `main`
 
-As you are working on your branch, changes may happen on `master`. Before
+As you are working on your branch, changes may happen on `main`. Before
 submitting your pull request, be sure that your branch has been updated
 with the latest commits.
 
 ```console
 git fetch upstream
-git rebase upstream/master
+git rebase upstream/main
 ```
 
 This may cause conflicts if the files you are changing on your branch are
-also changed on master. Error messages from `git` will indicate if conflicts
+also changed on main. Error messages from `git` will indicate if conflicts
 exist and what files need attention. Resolve the conflicts in each file, then
 continue with the rebase with `git rebase --continue`.
 
@@ -134,22 +136,22 @@ check your code style for linting errors without running tests, you can just
 run `npm run lint`. If there are errors, you can usually fix them automatically
 by running `npm run fix`.
 
-Linting rules are declared in [.eslintrc](https://github.com/cloudevents/sdk-javascript/blob/master/.eslintrc).
+Linting rules are declared in [.eslintrc](https://github.com/cloudevents/sdk-javascript/blob/main/.eslintrc).
 
 ## Submitting and Updating Your Pull Request
 
 Before submitting a pull request, you should make sure that all of the tests
 successfully pass by running `npm test`.
 
-Once you have sent your pull request, `master` may continue to evolve
-before your pull request has landed. If there are any commits on `master`
+Once you have sent your pull request, `main` may continue to evolve
+before your pull request has landed. If there are any commits on `main`
 that conflict with your changes, you may need to update your branch with
 these changes before the pull request can land. Resolve conflicts the same
 way as before.
 
 ```console
 git fetch upstream
-git rebase upstream/master
+git rebase upstream/main
 # fix any potential conflicts
 git push -f origin 48-fix-http-agent-error
 ```
@@ -166,7 +168,7 @@ for details.
 
 ```console
 git commit -m "fixup: fix typo"
-git rebase -i upstream/master # follow git instructions
+git rebase -i upstream/main # follow git instructions
 ```
 
 Once you have rebased your commits, you can force push to your fork as before.