Event type

[woksin]

Based of PR #17 Pull that in first

This introduces the new @eventType decorator, which in fact is just an alias for the @artifact decorator. I think that having the @artifact decorator makes sense. And it makes sense that the registration of Artifacts is done the way that it's done now.

[jakhog]

IMO we should not keep the @artifact decorator. Artifact is an abstract type, and it doesn't make sense to instantiate it - so keeping it does not really provide any value. It's ofcourse fine to keep a central store for all the artifacts, but I think the decorator should go.

[joelhoisko]

I guess this also affects how much will the user be dealing with the artifact terminology while using the SDK in general (bit off topic for this PR)

Will the user be making ArtifactId's etc? Should the user ever encounter the word artifact or is it something that is strictly internal to only us? What about when the user reads logs about artifacts, can they make the connection between an artifact and what they've been calling event types based on how they use the SDK?

[einari]

Artifacts is an internal terminology - developers don’t really work with these, they work with more concrete types like event types. From an SDK perspective, it does not add value to the developer having access to artifacts. While internally in the runtime, thats all we know

[woksin]

That's a good clear up. I'll happily embrace that 😁

[woksin]

The changes made to this PR effectively made it a breaking change by removing the @artifact decorator. We should publish a new major version and deprecate these versions (4.1.0) on npm @joelhoisko