New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide public ES modules #21
Comments
I understand the issue. If adding |
Thanks for the attention. Adding I was in the middle of PR when noticed that I overlooked The problem I noticed with both my build of Here's an example:
I found out that there are transpiled classes (namely |
So the issue is actually blocked by tree-shaking. For me The number of times they change the very base of the library is way too many. So for me was no surprise that when I try to upgrade my working For now, I will expose |
In the end, yes, proper tree-shaking is the reason why devs may prefer ES module import instead of other bundles. I'm not very fond of Babel for that reason, too. Typescript generates less spec-compliant but slimmer and cleaner code and can be used as plain JS transpiler, though it may have its own concerns with tree-shaking. I did a PR to Buble, hope this can provide a simple way to solve this. BTW, the package itself has Babel dev dependencies. They are currently unused, aren't they? |
I believe |
I will have to close this issue. |
I would expect that this will be naturally solved with new Buble release. Cannot test for now if this is true, but from now it seems that class annotations were the only obstacle. Of course, this should be addressed in both Rambda and Rambdax in order to work. |
Great to hear that. I do hope that you manage to reach a solution. Feel free to reopen this when that happens. |
new |
Thanks for your efforts. Yes, it is built as intended with new setup. There's a bug, it should be I have a couple of suggestions on current setup. Since rambda and rambdax are different packages it would be better to not include it into |
The bug is a nice catch, I was wandering why there is some issue with I am not sure what you mean by Now |
I mean that if one of project dependency uses Rambda and another uses Rambdax, this will result in two Rambda copies. Not a problem for me because I use Rambdax and tree-shake it, but since Rambda is relatively popular, this seems possible.
I wonder if this was necessary. Considering that Rambda switched to Rollup+Babel too, I suppose that treeshaking will now work with external Usually there are reasons to keep separate UMD and CJS builds if CJS can partially rely on external deps and contain |
My test with tree-shaking showed me that it doesn't work as great this way, that is why I went in this direction. I agree for this case when there are two copies of You rightly pointed that it is challenge to maintain two similar libraries and at one point I had enough of it. I feel that this is better option as My main task was to make development in I will close the issue, but you can comment further if you find that necessary. |
/es
package entry point is conventional in modern libraries.The suggestion is to provide
rambdax/es
imports in ES5 and ES module format , similarly to how it was done withramda/es
. Notice that Ramda modules are transpiled to ES5 to skip transpilation on bundling, and there is index reimporting file.Unlike
rambda/lib
,rambdax
doesn't contain separately built CJS modules.Currently it's possible to import modules as
rambdax/src/debounce
. The problem is thatsrc
is ES2017 and isn't published to NPM, it's also not a good habit to rely on internal package structure.The text was updated successfully, but these errors were encountered: