WIP: rework build system to use esbuild.

[diasbruno]

Fixes #1036.

This is an update to the build system to use esbuild.

It need to:

• Build a pre-compiled version
• Build a minified version
• Use src/index as main module file
• Run dev/examples server
• Run tests

[diasbruno]

Suggested change

	nativeBuildInputs = with pkgs; [jq nodejs_20 swc nodePackages.typescript-language-server];
	nativeBuildInputs = with pkgs; [jq nodejs_20 nodePackages.typescript-language-server];

[diasbruno]

@doeg What do you think about removing "Build an esm/cjs modules"?

I'm thinking in reducing the amount of artifacts and just a provide a minified version of the library, and, point to main file to "src/index.[tj]s" (this might fix the issue of using fork of this project.

[diasbruno]

We used to pre-compile the library because of some webpack loaders and babel transformers, but I think that if we move to functions and hooks, we can remove build step.

[doeg]

@diasbruno to tell you the truth, I haven't maintained a React library before and can't give you an informed answer from that perspective. 🤔

Please correct me if I'm wrong: my understanding is that CommonJS modules are typically intended for backend/node imports. I looked at Next.js as an example of server-side imports and it looks like even they support ESM these days. I agree that CommonJS is probably not the best fit for a front-end library like this one.

A question, though! 🙇 If the module distributes just the minified version of the library, wouldn't the entrypoint file still need to use ESM module syntax (or equivalent)?

[doeg]

This diff is amazing! 😂

[diasbruno]

If the module distributes just the minified version of the library, wouldn't the entrypoint file still need to use ESM module syntax (or equivalent)?

Depends on which version of the language (ES5, ES2015, ...) we compile it to.

If we don't pre-compile the library, users needs to have all the correct languages features to compile (classes, arrows and so on). But, if we move away from class components - I'm guessing, it will no longer be a problem.

I'm thinking on release this as v4-rc1, so we can give it a try and see how that works.

[diasbruno]

I'm going to drop esm/cjs for the first release candidate, so we can test it early.

[doeg]

Makes sense to me! Let me know if I can be helpful in testing or otherwise. 😸

[rdtabb]

@diasbruno hi! I wonder how the migration to esbuild is going? Can I help?

I really like your lib and have been using it in production at my job for over a year, then I saw this pr, and thought maybe I can be of some use. I have a pretty extensive experience in migrating legacy babel/webpack/plain-ol'-tsc build systems to swc/esbuild/vite-lib-mode etc. I also am quite experienced with maintaining react-js libraries (although all of them are private repos in my company).

So if you can bring me up to speed and maybe offload some work to me, I would be more than happy!

(i don't want to be a nuisance and just try to contribute stuff, who knows, maybe you already got everything figured out, he-he)

[diasbruno]

@rdtabb What made me pause the whole update process is that karma has been deprecated. We can't run the tests using jsdom, since we need to tweak some browser behavior (specially regarding "tabbing" inside the modal).

I've tried a few alternatives, but the process was really stressful.

If you want a really hard quest, you can take this branch (or create another one to give it a try). The goal would be to build and test on a real browser.

If you want to give it a try, I can help/assist with anything you need. Just let me know.