Comments (13)
Thanks for your efforts. Yes, it is built as intended with new setup.
There's a bug, it should be ./dist/rambdax.esm.js
instead of ./dist/rambdax.es.js
, https://github.com/selfrefactor/rambdax/blob/master/files/rollup.config.js#L12 . It's listed as rambdax.esm.js in package.json.
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 cjs
build (I guess that's the consequence of having it as dev dependency in src
), otherwise it could be discarded in favour of UMD module. And for umd
, it's good to have unminified .umd.js and minified .umd.min.js. There are no source maps but they would be usable for all dist modules.
from rambdax.
Great to hear that. I do hope that you manage to reach a solution. Feel free to reopen this when that happens.
from rambdax.
new Rambda
version will solve this, when new Rambdax
will use Rambda
as development dependency..
from rambdax.
I wonder if this was necessary. Considering that Rambda switched to Rollup+Babel too, I suppose that treeshaking will now work with external rambda dep and export * from 'rambda' that was previously used.
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 rambda
, but it is a downside I am willing to take.
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 Rambda
is relatively stable and doesn't change much.
My main task was to make development in Rambdax
easier for me and that was the main reasoning behind removing Ramda
as dependency.
I will close the issue, but you can comment further if you find that necessary.
from rambdax.
I understand the issue. If adding src
folder to NPM helps, then I can do that. The other suggestion is a bit blurry to me, so you either have to provide a bit more details or open PR, which I will accept.
from rambdax.
Thanks for the attention. Adding src
may help and would be a good thing. That's only a part of the problem. Since src
is ES2017, it forces a user to transpile package code while it could be just imported. This results in more cumbersome builds in my experience.
I was in the middle of PR when noticed that I overlooked /dist/rambda.m.js
which already does that (ES modules with ES5) and could be used for tree-shaking. Since rambdax/dist/rambda.m
import looks odd, I'd suggest to create /es.js
alias for it to comply with import * as R from
rambdax/es` convention, but the rest may work as is.
The problem I noticed with both my build of /es
and /dist/rambda.m.js
is that tree-shaking is awful when rambdax/dist/rambda.m
bundle is imported. Seems to be a problem of Microbundlem which is currently used in rambdax
, affects rambda
as well.
Here's an example:
import R as * from 'rambdax/dist/rambdax.m'
R.pickBy();
npx microbundle -i index.js -o dist --sourcemap false
results in 3.8Kb (1.5Kb gzipped) bundle, which is way too large for pickBy
. It should be x20 smaller.
I found out that there are transpiled classes (namely Switchem
) in the bundle that aren't related to a module in use (pickBy
) but aren't dropped by the minifier because they are transpiled to IIFEs and considered side-effects. Seems to be this problem. But Microbundle uses Buble which doesn't seem that advanced to cover that. I'm not sure if the problem can be fixed without ditching Microbundle and switching to Rollup+Babel 7. Any thoughts on that?
from rambdax.
So the issue is actually blocked by tree-shaking.
For me babel
is example why many developers hate Javascript
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 rollup
configuration, it resulted many babel
related errors. And that is the reason why I switched to microbundle
in rambda
and rambdax
as it was painful debugging.
For now, I will expose src
with the next version and meanwhile I will try to find some solution for tree-shaking.
from rambdax.
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?
from rambdax.
I believe babel
dependencies are leftovers from the previous setup. I will try upgrading microbundle
as that may solve the issue. Otherwise I will try to make rollup
works.
from rambdax.
I will have to close this issue.
I played with rollup
in order to fix tree-shaking, but Rambdax
remains unshakable. For the time being, this is not something that can be easily solved. In the future there are some ugly options, that may be applied, but for now this is not the case.
from rambdax.
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.
I'm working with Rollup setups aimed for tree-shaking, so I'm positive the problem is solvable.
from rambdax.
The bug is a nice catch, I was wandering why there is some issue with tree-shaking
. It is fixed now. Also sourcemaps are included in the latest release.
I am not sure what you mean by Since rambda and rambdax are different packages it would be better to not include it into cjs build
Now Rambda
stays as dev dependency only in order to be used in support scripts. It has no direct connection to the build process. The latest major change in Rambdax
was to copy all of Rambda's src
folder into src/rambda
and change all import statements.
from rambdax.
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.
The latest major change in Rambdax was to copy all of Rambda's src folder into src/rambda and change all import statements
I wonder if this was necessary. Considering that Rambda switched to Rollup+Babel too, I suppose that treeshaking will now work with external rambda
dep and export * from 'rambda'
that was previously used.
Usually there are reasons to keep separate UMD and CJS builds if CJS can partially rely on external deps and contain require('rambda')
, while UMD contains bundled rambda
. At least that's how UMD and CJS builds differ in other libs like React.
from rambdax.
Related Issues (20)
- Async version of R.find HOT 3
- removeIndex has backward arguments HOT 3
- rejectIndexed is missing HOT 2
- Broken examples HOT 8
- Dealing with readonly types returned from immutable array operations HOT 2
- Error in /index.d.ts and /immutable.d.ts HOT 1
- mapArray filterArray curried error HOT 3
- `dropRepeatsWith` takes an equality predicate but documents suggests it takes projector HOT 3
- Function throttle returned undefined HOT 3
- Utility Request: R.toUpcase (ie: Capitalize) HOT 2
- debounce and repl example are broken HOT 1
- Tests? HOT 2
- R.count not working as expected HOT 3
- uniqBy is different from ramda HOT 5
- Missing R.unnest HOT 3
- isFunction not removed from docs HOT 3
- Add differenceWith HOT 2
- Using R.prop with array utility methods returns unknown[] after version 9 HOT 5
- R.partial types and implementation are in conflict HOT 2
- Improve mapToObject types HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rambdax.