I'm experimenting with a fork of this repository and considering migrating the toolchain to the following configuration:
Converting all files to fully typed TypeScript and emit TypeScript type definitions
Leverage TS types to generate API documentation using TypeDoc instead of manually maintained JSDoc
Use parcel instead of gulp+browserify to build separate builds for CommonJS, ES modules and global targets for use in NPM modules
Possibly enable GitHub Actions to build and deploy documentation without manual steps
This would solve a number of problems:
Enables strict typing when importing the library in other projects — currently no types are provided, and there is a lot of trial-and-error for users of the library. It also enables use of private, public and protected keywords for better access hints.
Leveraging TS types instead of JSDoc would mean that documentation would always be in sync with code.
Currently, only CommonJS modules are exported, which means that projects consuming the library with ES modules are left out in the rain. Multiple build targets means that specific versions of the builds would enable all consumers and bundlers to correctly include the right build file to use.
README and other documentation seems to be quite out of sync with the repository's latest version (some examples use 1.x, some 2.x). This could be improved by moving the documentation into the TypeDoc build flow to prevent deviation and deduplicate code.
Would this be something the team would consider merging upstream?
I'm experimenting with a fork of this repository and considering migrating the toolchain to the following configuration:
gulp
+browserify
to build separate builds for CommonJS, ES modules and global targets for use in NPM modulesThis would solve a number of problems:
private
,public
andprotected
keywords for better access hints.Would this be something the team would consider merging upstream?