Skip to content
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

Question regarding debug dependency #713

Closed
pablopalacios opened this issue Jun 18, 2021 · 6 comments
Closed

Question regarding debug dependency #713

pablopalacios opened this issue Jun 18, 2021 · 6 comments

Comments

@pablopalacios
Copy link
Contributor

@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
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor

I'm fine with removing debug entirely

@redonkulus
Copy link
Contributor

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
Copy link
Contributor Author

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!

@roderickhsiao
Copy link
Contributor

roderickhsiao commented Jul 20, 2021

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')

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants