bullmq
bullmq copied to clipboard
feat: add Serialize type
Changelog
Currently BullMQ is lying with the data type workers operate with.
Consider the following code:
type Payload = {
date: Date;
};
new Worker<Payload>("queue", async ({ data: { date }}) => {
// Typescript is ok with this, but Javascript will happily throw a TypeError
console.log(date.toISOString());
});
This is because the type we use does not correctly reppresent the data object we think we operate with. You can imagine data declared as data = JSON.parse(JSON.stringify(...));.
This is the same issue the remix.run team had to deal with a while ago (Indeed the type I added is actually just a little refactor of it).
This PR adds the Serialize type used by the Worker class.
The Serialize type serializes the DataType we pass to the Worker. With this the previous example correctly raise a compilation error in ts.
Notes
Please note that this is likely to be a breaking change, since some users may just pass around the data object without any checking.
This is an interesting PR. I wonder if you have a link with more information regarding the type Serialize, as I guess this has been discussed in some other forums, it is not completely trivial to understand how it works. Also as you mentioned, it will imply a breaking change so we need to plan this change carefully.
@manast the primary ref for this is the type Jsonify from type-fest.
Other packages have also been proposed on SO, but these are primary focusing on the serialization of the value, not the type.
how can we know that the implementation of Serialize is correct?
The remix team uses a bunch of utilities that will raise a typescript error if something is wrong. I can implement those as well.
Check them here.
Is the remix license incompatible with BullMQ? I wondering in case we could just use that code as is?
The licensing is not really my best field, but remix.run is under the MIT, so it should be fully compatible with BullMQ.
in case we could just use that code as is
I truly understand your worries but the version in this PR is a little better to the remix.run, primary on the Prettify type. (The remix.run one is declared erroneusly)
I think that before we can merge this we are going to need a pretty good test coverage to avoid breaking existing codebases if for instance typescript would complain on legitimate types and so on.
I completely agree, let me know how I can help