Closed jwulf closed 3 years ago
I'll try and address it this week.
I've published an alpha of zeebe-node 1.0.0. You can install it with npm i zeebe-node@alpha
. It works with 1.0.0-alpha3 Zeebe docker image from Docker Hub.
Links to change log and Readme here: https://forum.camunda.io/t/zeebe-node-1-0-0-alpha3-client-available-for-testing/2113
@jwulf why is the createWorker method in the ZBClient deprecated? And where can I find the 1.0.0 branch?
@jwulf I've created a new release (2.0.0) but trying to go through your deprecations I found something odd. The handles gets 3 variables, job, complete, worker. When you wish to use complete.success({}) as before is says it's deprecated and you should use the job.complete function, but according to the "Job" interface, there is no such function.
When you debug it in runtime, the job does have a complete function, so there is some issue with the interfaces.
The two are related. The CHANGELOG here has details: https://github.com/jwulf/zeebe-client-node-js/blob/1.0.0/CHANGELOG.md
The createWorker
method with multiple parameters is deprecated in favour of the object constructor signature. That one returns the new job interface.
So the zeebe-decorator.ts
file would be something like this on line 66:
const zbWorker = this.client.createWorker({
id: workerOptions.id,
taskType: workerOptions.taskType,
taskHandler: workerOptions.handler,
...workerOptions.options
});
Great, I'll check it.
Anyway there is already a published working version.
P.S Can you please update the zbctl npm package to support v1?
@jwulf So you are right, but you are wrong :)
The new method accepts a taskHandler where the job is defined as follows:
Readonly<Job<WorkerInputVariables, CustomHeaderShape> & JobCompletionInterface<WorkerOutputVariables>>
We need a proper interface that encapsulates this.
For now, I'm exposing my own interface that mimics it, but this should be exposed properly. v2.0.1 has been published :)
That's not an interface and not something I'd like to put in each handler method. BTW, WorkerInputVariables, CustomerHeaderShape, and WorkerOutputVariables are all not public interfaces and after lots of digging they are just renaming of other interfaces, that's also super misleading for a user.
So, something like this?
export interface ZeebeJob extends Job<IInputVariables, ICustomHeaders>, JobCompletionInterface<IOutputVariables>
{}
Zeebe 1.0.0-alpha7 is about to come out. It has a breaking API change in the grpc protocol, so I'm going to release another zeebe-node
package. The only change for you to pull that in should be a dependency version update.
I'll see if I can do this interface at the same time.
Yep, that's exactly what I've created for now inside my library!
When is the final version expected?
The 1.0.0-alpha-7 version exports ZeebeJob
with that shape.
When is the final version expected?
Soon, very soon.
Can you please update the zbctl npm package to support v1?
zbctl
v.1.0.0-alpha.7 has been published on NPM.
zeebe-node 1.3.0* is out on NPM, and zbctl is updated to 1.0.0.
*1.0 - 1.2 were used two years ago under the old versioning scheme, before we synced with Zeebe release numbering.
Thanks! As far as I know everything should be v1 compatible now.
Epic!
Zeebe 1.0.0 is coming down the pipeline. It is roughly expected in April. It contains breaking changes to the client API. I'm expecting to see these changes merged in alpha2 in March.
I've created a branch of zeebe-node for 1.0.0 that deprecates the v0 API methods on the zeebe-node API surface and redirects them to the new v1 API methods. It should be a drop-in replacement with no need to change the NestJS integration code (and you can change it to use the new v1 API methods, and should at some point).
Applications using the v1 package cannot communicate with v0 brokers. The v1 package is backward compatible with v0 application code, but not v0 brokers.
More details here: https://forum.zeebe.io/t/changelog-for-zeebe-client-lib-maintainers/2064