Stale libraries are more likely to contain known security vulnerabilities.

I know it's bad practice, but I just checkin vendor files/libs to source control. Makes auditing new releases of libraries a bit easier. Assuming they aren't binaries of course.

I also like doing this, but with node, you have a massive tree of thousands of files. It's crazy and gross.

Yarn 2 pnp kinda fixes this

I don't recommend this approach

I haven't had issues yet, but it's considered bad practice for a reason. What headaches am I in store for?

You're committing something that is not a part of your source code into your version control system, assuming your source code is git, this is irrevocable without rewriting history.

It's mainly a nuisance. It takes up unnecessary space. Introduces possible annoying merge conflicts etc etc and it's not trivial to remove it.

As reference, I migrated repositories from TFVC to git. One team relies on checking in packages into source control, another one does so far less. One repo is significantly nimbler.

Checking packages into source control is making your VCS a package manager. Presumably you have one. Don't hammer nails with your screwdriver

The benefit of having your dependencies vendored is that you have everything needed to build your application without having to download stuff from the internet. You get to ensure what exactly makes it into your application. Yes, it will increase the repository size, but I don't see why merge conflicts would be a problem since you are just replacing a file with a new version.

> you have everything needed to build your application without having to download stuff from the internet

that's using version control to act as a proxy. AFAIK, a lot of package managers already cache local copies

> You get to ensure what exactly makes it into your application

sorry but i don't follow

> I don't see why merge conflicts would be a problem since you are just replacing a file with a new version

Are you working alone?

>AFAIK, a lot of package managers already cache local copies

But this cache is usually not easily transferable to someone compared to them just cloning a repo.

>sorry but i don't follow

You have the source code to all of the dependencies in your application.

>Are you working alone?

How many forks of a dependency do you use? Just using the master branch and upgrading along that should be good enough for 99% of your dependency.

> But this cache is usually not easily transferable to someone compared to them just cloning a repo

right, so they need to download "stuff from the internet". it Doesn't matter much if that stuff is from a remote repo or hosted by a package repository. Except if it's architecture dependent, in which case you definitely don't want to share across architectures. Not to mention they may already have a viable copy in a proxy or cache

> You have the source code to all of the dependencies in your application

I'm afraid I still don't follow

> How many forks of a dependency do you use? Just using the master branch and upgrading along that should be good enough for 99% of your dependency

Well, if I was expecting things to not break I'd never follow upstream master for a dependency.

But the question pertained to merge conflicts. If several people track the same remote and check in dependencies into VCS I'd expect annoying merge conflicts

Or are we perhaps misunderstanding each other? I'm not sure I follow what you mean by forks. Releases are typically on different branches or tags

I imagine your commit log would be polluted with commits just for changes in the packages.

You would have one anyways for changing the lock file or whatever. Changing your dependencies is something that you may want to be able to undo. It's useful to be able to go back to a known working version of your program with versions of your dependencies that you know work.

Git submodule documentation explicitly says[1] it's designed for adding 3rd party libraries to a project in this exact scenario.

[1] https://git-scm.com/book/en/v2/Git-Tools-Submodules#:~:text=....

I’ve been doing it witb Yarn 2 / pnp and it has been great so far.

You checkout a project and start it. No downloading required, and no 10000s of files.