Open diasbruno opened 4 months ago
@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.
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.
@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)?
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.
I'm going to drop esm/cjs
for the first release candidate, so we can test it early.
Makes sense to me! Let me know if I can be helpful in testing or otherwise. 😸
Fixes #1036.
This is an update to the build system to use esbuild.
It need to:
src/index
as main module file