6 ms·

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

by temp12192021 5y ago

tobyhinloopen 5y ago
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.
cerved 5y ago
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
- charcircuit 5y ago
  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.
  - cerved 5y ago
    > 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?
    - charcircuit 5y ago
      >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.
      - cerved 5y ago
        > 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
  - arvinsim 5y ago
    I imagine your commit log would be polluted with commits just for changes in the packages.
    - charcircuit 5y ago
      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.
    - deleted 5y ago
      [deleted]
- Brybry 5y ago
  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=You%E2%80%99re%20likely%20to,your%20commits%20separate https://git-scm.com/book/en/v2/Git-Tools-Submodules#:~:text=....

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

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.

cerved 5y ago

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

charcircuit 5y ago
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.
- cerved 5y ago
  > 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?
  - charcircuit 5y ago
    >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.
    - cerved 5y ago
      > 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
- arvinsim 5y ago
  I imagine your commit log would be polluted with commits just for changes in the packages.
  - charcircuit 5y ago
    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.
  - deleted 5y ago
    [deleted]
Brybry 5y ago
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=You%E2%80%99re%20likely%20to,your%20commits%20separate https://git-scm.com/book/en/v2/Git-Tools-Submodules#:~:text=....