Removing dependencies that can be replaced with very low amount of code

[ClementEXWiki]

We currently use some dependencies that can be easily replaced by a few lines of non-complex code.

For instance, in some packages of Cristal, we include the entire lodash-es dependency just to use its debounce function, and nothing else. That function is extremely simple and can be written by hand very easily (or we can even pull the code from Lodash if required).

I think adding an entire dependency just for a function or two is problematic for multiple reasons:

1. It’s one additional dependency in the project to deal with
2. It increases the attack surface in case of security issue
3. It’s one more package to potentially upgrade every now and then
4. If the package’s tree-shaking implementation or our integration is not perfect, some dead code will be included in the final assets

For all these reasons I think it would reasonable to remove such dependencies.

What do you think?

[mleduc]

@ClementEXWiki

It’s one additional dependency in the project to deal with

How do you define the limit of what is acceptable as a dependency and what is not?

@ClementEXWiki

It increases the attack surface in case of security issue

Can you develop? I’m not sure if I understand how a small piece of homemade code can have better security than a widely distributed library.

@ClementEXWiki

It’s one more package to potentially upgrade every now and then

What’s exactly the issue with that? We already rely on dozens of libraries that we have to upgrade regularly.

@ClementEXWiki

If the package’s tree-shaking implementation or our integration is not perfect, some dead code will be included in the final assets

If there is indeed a problem we that, we need to fix it. But the issue in this case is not to have dependencies.

@ClementEXWiki

For all these reasons I think it would reasonable to remove such dependencies.

What do you think?

I’m currently -1. Every line of code we have to maintain is a liability, and our priority is to only have to maintain code that is specific to our code business (i.e., things that are not already provided by other vendors).

[ClementEXWiki]

@mleduc

How do you define the limit of what is acceptable as a dependency and what is not?

When it’s more than a few lines of code. We could put some hard limit but I think if we have more than 50 lines to copy over, it’s better to not have a dependency.

@mleduc

Can you develop? I’m not sure if I understand how a small piece of homemade code can have better security than a widely distributed library.

When we pull in a dependency, we have to vet for that dependency, it’s another dependency that could be compromised by a third-party (where as we have more control on our first-party code), and we also don’t pull a ton of code - only the small amount we need.

@mleduc

What’s exactly the issue with that? We already rely on dozens of libraries that we have to upgrade regularly.

The less libraries we have, the better. We regularly have some dependencies upgrade that require us to change some code because compatibility has been broken or because it interferes with another library.

@mleduc

If there is indeed a problem we that, we need to fix it. But the issue in this case is not to have dependencies.

Sorry I don’t really get what you’re saying here?

@mleduc

I’m currently -1. Every line of code we have to maintain is a liability, and our priority is to only have to maintain code that is specific to our code business (i.e., things that are not already provided by other vendors).

I think adding a dependency adds a higher liability as we now rely on an entire third-party codebase with its own set of security rules, maintenance, compatibility etc.