Event receivers in the wild may not always know what version or mode an
incoming event is. Instead of requiring developers to inspect the headers
themselves, the SDK should provide an HTTP receiver that is capable of
figuring out what the version and mode (structured/binary) of an incoming
event is and handle it appropriately.
In determining the best way to expose this, I chose to modify the API a
little bit. Now, instead of `const CloudEvent = require('cloudevents-sdk');`
users need to destructure it.
```js
const { HTTPReceiver, CloudEvent } = require('cloudevents-sdk');
```
This change should not be backported to 1.x.
Fixes: https://github.com/cloudevents/sdk-javascript/issues/93
Signed-off-by: Lance Ball <lball@redhat.com>
Enforce the use of `let` and `const` by using elsint rules.
When creating the eslint configuration, I had assumed that
`extends: eslint:recommended` would have covered this, but
apparently not!
Existing usage of `var` fixed with `npm run lint -- --fix`.
Fixes: https://github.com/cloudevents/sdk-javascript/issues/97
Signed-off-by: Lance Ball <lball@redhat.com>
This commit removes support for the v0.2 specification. It also removes the
`contenttype` attribute from the `CloudEvent` object. While the HTTP protocol
binding specifies that in binary mode, the `datacontenttype` attribute should
map to the HTTP Content-Type header, that doesn't mean that the `CloudEvent`
object should have a `contenttype` property.
Fixes: https://github.com/cloudevents/sdk-javascript/issues/61
Fixes: https://github.com/cloudevents/sdk-javascript/issues/66
Signed-off-by: Lance Ball <lball@redhat.com>
Automatically fixed > 2000 issues. The remaining 200+ issues need
to be fixed by hand. Additionally, all strings are double quotes
which is not typically standard and I wonder about fixing that too.
Signed-off-by: Lance Ball <lball@redhat.com>
Lance Ball
Helio Frota
Grant Timmerman
Fabio José