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>
This commit pulls the constants up from the lib/bindings/http/constants.js
and exports them in the top level index.js. There are some elements of the API
where we expect users to provide constant values, and this makes it easier for
them to be sure the values they provide are what is expected.
I've also added two new constants: `BINARY` and `STRUCTURED`.
Signed-off-by: Lance Ball <lball@redhat.com>
This change adds a `ValidationError` type that extends `TypeError`. Any time a `CloudEvent` cannot be received and created with the given input, this error will be thrown. Tests have all
been updated to check for the error type.
Signed-off-by: Lance Ball <lball@redhat.com>
This commit removes the require of uuid from this test and uses a
hardcoded value for the 'id' constant instead.
The motivation for this is that the value for 'id' does not need to be
generated for each test run, and fewer requires helps readabilitly I
find.
Signed-off-by: Daniel Bevenius <daniel.bevenius@gmail.com>
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
Daniel Bevenius
Grant Timmerman
Helio Frota
Fabio José