This commit separates the spec compliance table in the README.md file
into three: the core spec, event formats, and transport protocols.
Fixes: https://github.com/cloudevents/sdk-javascript/issues/166
Signed-off-by: Lance Ball <lball@redhat.com>
BREAKING CHANGE:
* Extension names are now validated during object creation. The values are defined by the specification, and can be lowercase(a-z) or digits(0-9) and must be no longer that 20 characters
Signed-off-by: Lucas Holmquist <lholmqui@redhat.com>
BREAKING CHANGE:
* This change makes the CloudEvent Read-only and validates the input during object creation.
* To augment an already created CloudEvent object, we have added a `cloneWith` method that takes attributes to add/update.
Signed-off-by: Lucas Holmquist <lholmqui@redhat.com>
Even though the underlying structured and binary receivers already sanitize
the headers, this needs to be done at the receiver.accept() level since
the headers are inspected there to determine what mode the event is being
sent as.
Signed-off-by: Lance Ball <lball@redhat.com>
* chore(actions): don't auto-close stale issues and pull requests
Open issues and pull requests should be closed by a human who has considered
the issue/pr and made a choice based on the content of the issue/pr and the
state of the repository.
What this means in practice is that some issues will stay open for a long
time, even if they are stale. They may be open because it really is something
that will be considered for future work. Periodic issue triage should be
done by the maintainers, and if an issue _should_ be closed - for example,
the issue is no longer relevant - then a maintainer can close it.
Signed-off-by: Lance Ball <lball@redhat.com>
This is a major rewrite of the entire codebase into TypeScript. Nearly
all tests have been retained except where behavior is significantly
different. Some highlights of these changes:
* lowercase all CloudEvent properties and fix base64 encoded data
Previously there was a format() function that would convert a CloudEvent
object into JSON with all of the properties lowercased. With this rewrite
a CloudEvent object can be converted to JSON simply with JSON.stringify().
However, in order to be compliant with the JSON representation outlined in
the spec here https://github.com/cloudevents/spec/blob/v1.0/json-format.md
all of the event properties must be all lowercase.
* lib(transport): make transport mode an Enum
* src: allow custom headers (#1)
* lib(exports): export explicitly versioned names where appropriate
* lib(cloudevent): modify ctor to accept extensions inline
* lib(cloudevent): make extensions a part of the event object
* test: convert all tests to typescript
* examples: update all examples with latest API changes
* docs: update README with latest API changes
* src: add prettier for code style and fix a lot of linting errors
* lib: move data decoding to occur within the CloudEvent object
Signed-off-by: Lance Ball <lball@redhat.com>
There is nothing really to do in order to support events over websockets.
Since a `CloudEvent` can easily be represented in full with JSON, it can
be sent over a websocket as `event.toString()`. This example illustrates
sending a `CloudEvent` over websocket from a browser or CLI.
Fixes: https://github.com/cloudevents/sdk-javascript/issues/156
Signed-off-by: Lance Ball <lball@redhat.com>
This commit introduces a second `tsc` execution which generates JS in ES5 form.
Then, webpack is used to generate a browser bundle.
Fixes: https://github.com/cloudevents/sdk-javascript/issues/94
Signed-off-by: Lance Ball <lball@redhat.com>
* feat!: pass extension into the constructor.
* This allows someone to pass an extension/extensions into the CloudEvent contructor when creating a CloudEvent.
fixes#209
Signed-off-by: Lucas Holmquist <lholmqui@redhat.com>
* lib: remove specversion from the required attributes in receiver.accept()
The `HTTPReceiver` class' `accept()` method should not have a typescript
type designation of `{ specversion: string }` for the `body` parameter
because the event could (and often is) in binary form, which means that
the `specversion` property won't be there.
This commit changes the method signature to:
`accept(headers: {}, body: {}) : CloudEvent`
Signed-off-by: Lance Ball <lball@redhat.com>
This commit modifies the existing TypeScript files with improved
(read: functional) typings for function parameters. This became an
issue when trying to use the module in an existing TypeScript module.
Tests for the TypeScript files have been moved to a new test folder
specifically for testing TypeScript usage via ts-node.
Signed-off-by: Lance Ball <lball@redhat.com>
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>
GitHub will not set secrets in the environment when a pull request is submitted
from a forked repository. This commit modifies the CI workflow to only send
the report when the API token has been set. It also consolidates the two
workflows into a single one which shares coverage data between jobs.
Fixes: https://github.com/cloudevents/sdk-javascript/issues/190
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 commit turns the headerByGetter Object into a Map to reduces some
code duplication an hopefully improve readability a little.
Signed-off-by: Daniel Bevenius <daniel.bevenius@gmail.com>
This commit introduces TypeScript checks and generates type declarations
for the existing JavaScript codebase using `tsc` prior to running the linter task.
Ref: https://github.com/cloudevents/sdk-javascript/issues/9
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 commit removes the 'result' variable form the utility function
asData. The motivation is to improve readability.
Signed-off-by: Daniel Bevenius <daniel.bevenius@gmail.com>
This commit removes the version variable from getVersion and updates the
code to use return statements to be consistent with other functions in
this file, like getMode and accept.
Signed-off-by: Daniel Bevenius <daniel.bevenius@gmail.com>