yahoo/fluxible

Question regarding debug dependency

pablopalacios opened this issue · 6 comments

pablopalacios commented

@redonkulus there are many yahoo libraries that have debug as dependency. Almost all fluxible packages have it but I can also mention fetchr and routr as well. Since most of these packages are not tree-shakeable, unless we do something smart with webpack, we can get debug and ms libraries duplicated in our bundle many times. For instance, in my bundle, the following packages are including debug:

  • dispatchr
  • fluxible
  • fluxible-router
  • fluxible-plugin-fetchr
  • routr

debug has a dependency on ms package and together they make 4.2kb to be parsed by the browser. This means 21kb in my case (basically the same size as lodash on fetchr prior the change we did this week).

So, what do you think would be the right approach to follow here:

  1. Completely remove debug as dependency. It's the easiest one to do, but would require major release and it would lose functionality.
  2. Make all libraries tree-shakeable (es modules and babel). Medium effort. It would introduce dependency on babel which could be good to prevent errors like the fetchr one we had this week but yeah, tooling gets complex and we still have to make sure that all packages use the same debug version. One good thing is that we would keep the functionality.
  3. Try to come up with something smart and just use debug if NODE_ENV is development. This seems to be the hardest one to do (and I'm not sure if it would be possible) since we would probably need to refactor all libraries to support a different configuration based on environment. The good thing is that we would not include debug on production bundles (which could also be a bad thing).

Is there anything else that we could do?

2021-06-18-223122_586x754_scrot

redonkulus commented

I've been thinking about this as well. Is each of our OSS library using a different version of debug? Otherwise, I thought they would all be deduped by webpack.

pablopalacios commented

Most of them has ^2.0.0 as dep. In my package-lock they are all in 2.6.9 so I would also expect to have it deduped by webpack automatically, but it doesn't.

redonkulus commented

I'm fine with removing debug entirely

  • 🎉1
redonkulus commented

Most of them has ^2.0.0 as dep. In my package-lock they are all in 2.6.9 so I would also expect to have it deduped by webpack automatically, but it doesn't.

Its odd that webpack is not deduping it, maybe a webpack config issue?

pablopalacios commented

I mean, I'm not a webpack expert. Here we use a quite plain configuration. I tried to play with the split chunks optimization but I didn't get any further. But the issue is also visible in the examples and there you can see the webpack configuration.

But anyway, I saw that you merged and released everything, thanks for that!

  • 🎉1
roderickhsiao commented

in our project we set a module alias replacement to make sure all package is using the same version of app level of debug at least at client side bundle, just f.y.i

debug: path.resolve(__dirname, '../node_modules/debug')
  • 👍2