This extracts all of the attributes from a `CloudEventVX` that
are not generated by the constructor (id and specversion) into their
own `CloudEventVXAttributes` interface which the `CloudEventVX`
interface extends. This allows TS devs to optionally provide `id`
and `specversion` with proper autocompletion.
Additionally, I have added a union type, `CE` in `cloudevent.ts` which
represents any of `CloudEventV1`, `CloudEventv03`, `CloudEventV1Attributes`
and `CloudEventV03Attributes` interfaces.
Finally, this commit changes all of the user facing API to be `.ts` instead
of `.js` files.
The existing documentation in `./docs` was removed. It should be replaced with generated
HTML from tsdocs, pending some other method of publishing API documentation. That will
come as a separate, docs-only PR.
Fixes: https://github.com/cloudevents/skd-javascript/issues/188
Signed-off-by: Lance Ball <lball@redhat.com>
This commit makes a substantial change to the API, changing the CloudEvent class
to accept properties as an object in the constructor. For example:
```js
const CloudEvent = require('cloudevents-sdk');
// all event properties except extensions may be set in the constructor
const event = new CloudEvent({
source: 'http://my.event.source',
type: 'test-event-type'
});
// get and set all properties standard property notation
console.log(event.time); // the event timestamp
event.subject = 'my event subject';
```
Signed-off-by: Lance Ball <lball@redhat.com>
This is a breaking change.
This commit makes a number of changes to the HTTP bindings code in an attempt
to simplify its usage and implementation. From a very high level, this inverts
the existing dependencies.
As an example, consider `lib/bindings/http/receiver_structured_1.js`.
https://github.com/cloudevents/sdk-javascript/blob/v1.0.0/lib/bindings/http/receiver_structured_0_3.js
This class instantiates `lib/bindings/http/receiver_structured.js` and delegates
its function invokations to it. This had the effect of requiring a user to know what
event versions they would be receiving. And for me personally was a little confusing
as a maintainer.
The change introduced here reverses that logic, so that the version agnostic receiver
is what the user instantiates. It instantiates the approrpiate version of a specific
receiever and delegates to it - reversing the dependencies.
I've also moved all of the top level directories related to HTTP versions into
`lib/bindings/http/v1` and `lib/bindings/http/v03` and generally done some rearranging
to make the repository structure cleaner and more organized.
Signed-off-by: Lance Ball <lball@redhat.com>
* feat!: expose a version agnostic event emitter
This is a breaking change.
This commit exposes an HTTP based event emitter that simplifes the API.
To use it, simply import the SDK and start emitting. The default spec
version is 1.0, but you can use 0.3 by supplying that to the constructor.
By default, CloudEvents are emitted in binary mode, but this can be changed
by providing the "structured" parameter to the `send()` function.
This commit also eliminates the version specific emitters and receivers
from the `v1` and `v03` exports, and eliminates the explicit usage of
versioned emitters from `lib/bindings/http`.
Finally, the CE headers can be retrieved from the emitter for a given
event by passing the event to the `headers()` function.
Fixes: https://github.com/cloudevents/sdk-javascript/issues/124
Fixes: https://github.com/cloudevents/sdk-javascript/issues/149
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>
Lance Ball
Fabio José