4 ms·

There’s no reason people can’t keep local caches of these libs if it is a major concern. This seems like a non issue.

by rajin444 5y ago

MaxBarraclough 5y ago
Stale libraries are more likely to contain known security vulnerabilities.
- temp12192021 5y ago
  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.
  - cerved 5y ago
    I don't recommend this approach
    - temp12192021 5y ago
      I haven't had issues yet, but it's considered bad practice for a reason. What headaches am I in store for?
      - 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.
        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]
        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.
      - 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.
  - jay_kyburz 5y ago
    I also like doing this, but with node, you have a massive tree of thousands of files. It's crazy and gross.
    - tobyhinloopen 5y ago
      Yarn 2 pnp kinda fixes this
- rajin444 5y ago
  You’re free to update as you like. It’s entirely possible to audit your local packages. Letting maintainers update your projects is a convenient feature. If it is a liability in your use case you can work around it. Yes it will take more effort, but your use case justifies it.

There’s no reason people can’t keep local caches of these libs if it is a major concern. This seems like a non issue.

MaxBarraclough 5y ago

Stale libraries are more likely to contain known security vulnerabilities.

temp12192021 5y ago
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.
- cerved 5y ago
  I don't recommend this approach
  - temp12192021 5y ago
    I haven't had issues yet, but it's considered bad practice for a reason. What headaches am I in store for?
    - 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.
        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]
        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.
    - 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.
- jay_kyburz 5y ago
  I also like doing this, but with node, you have a massive tree of thousands of files. It's crazy and gross.
  - tobyhinloopen 5y ago
    Yarn 2 pnp kinda fixes this
rajin444 5y ago
You’re free to update as you like. It’s entirely possible to audit your local packages. Letting maintainers update your projects is a convenient feature. If it is a liability in your use case you can work around it. Yes it will take more effort, but your use case justifies it.