Move typescript definitions of @types/workerpool into the library and bring the definitions up to date

[josdejong]

Having the type definitions in the repo itself will make it easier to keep the definitions on par with the API.

Anyone able to help out here?

[1valdis]

I can try this. What would be the plan here? Do I just make a merge request with index.d.ts (with corrections if necessary)?

[josdejong]

Thanks Vladyslav, that would be great!

I expect what we need is:

• a file types/index.d.ts containing the types to be published
• a file test/types/index.ts to test the types and verify that they all work, and a script which runs the file

If you have thoughts or ideas I would love to hear them.

[1valdis]

Do you want the script to be run from terminal, like npm run test-types?

[josdejong]

Yes indeed. I think we can extend the existing "test" script to also run the tests for the typings

[1valdis]

Sounds good, I'll research for a bit and be right back with questions/proposals.

[1valdis]

I see that on #54 you suggested a move to Typescipt. If the library is moved to Typescript then there would be no need in writing index.d.ts by hand and maintaining it. Are you still considering the move?

[josdejong]

Yes definitely, I would like to move workerpool to TypeScript and ES modules. I haven't found time for that refactoring so far.

[1valdis]

I can consider refactoring to TypeScript that would compile to ES Modules. Some packages are dropping CommonJS support completely at this point, for example file-type@16 and up only works in ES Modules. Would you consider that as well?

[1valdis]

I'm asking about dropping CommonJS because I haven't had experience with publishing both CommonJS and ES Modules builds in one npm package. However judging by the available resources, that can be made quite straightforwardly as well, so there may be no need in dropping CommonJS :)

[josdejong]

I can consider refactoring to TypeScript that would compile to ES Modules

wow that would be awesome! Please be aware that this will really cost some time. There are for example some specific scripts to generate an embedded worker, that may complicate things.

At this point I think the library should generate&publish both ESM and UMD (currently, only UMD is published), and ideally the npm package should stay backward compatible. It requires some work to set up a build script for that, but that ensures a smooth transition. Does that make sense?

I do have experience with such a setup: I recently did that for https://github.com/josdejong/lossless-json. Maybe that setup can be of help.

[1valdis]

Does that make sense?

It sure does. I'm looking at what realistically needs to be supported, or if not then what can be cleaned up as not needed anymore.

For example, what's the ES version requirement? Do we want to still compile to ES5? Otherwise I think there's no need for, for example, Promise polyfill? What's the choice between "we need to keep backwards compatibility at all cost" and "whoever needs to run this thing on IE10 can just keep using workerpool@6 or lower"?

I don't see engines section in package.json. What is the minimum Node.js version for this to run? Oldest LTS at the moment is 14. If we take it as a minimum, do we need to keep child_process option considering that worker_threads is available in all versions at this point?

Do you want to keep gulp here? In loseless-json I only see rollup, however there's nothing like embeddedWorker generation.

[josdejong]

Good point. With backward compatible I mostly meant that when I use workerpool in some up-do-date project, and upgrade to the next version of workerpool, then ideally everything should just keep working. We should definitely keep support for child_process. To minimize the amount of moving parts, I think it would be good to limit this refactor to syntactic changes in the code (from CommonJS to ESM, and add types), and not make functional changes.

• I think we should drop support for IE11 and older (has reached EOF)
• We should support node.js 14 and newer (12 has reached EOF)

I think we should get rid of gulp since it is not maintained anymore. rollup can do the building indeed, and we can move code for embeddedWorker in a regular node.js script.

[1valdis]

Sounds good. Back to the Promise polyfill, do we keep it or not? Since we won't compile to ES5, then the next is ES6 and Promises are a feature of ES6, so should be safe to use native Promises?