Vendoring Dependencies

You may sometimes need to Vendor your dependencies if they come from an unstable source.
The concept of Vendoring a dependency is essentially the concept of building from a local copy of a library rather than relying on the third parties source. You essentially become the vendor of the package.
Vendoring may be necessary if the package owner doesn't release frequently or if you need to create a change to the package that the owner won't accept.
OnePub lets you Vendor a package and subsequently share it with your team or simply your other projects.

When don't you need to vendor packages?

Any released version of a package published on doesn't need to be vendored providing you fix the version of the package within your pubspec.yaml.
Just because a package is released to (or OnePub) doesn't mean you can trust it, but you can trust that a specific version won't change.
If your organisation requires that you audit any packages used in your project then you must pull the source of the package from (or OnePub) rather than from git. The reason for this is that you need to ensure you are auditing the actual code that makes up the version, not just some source code that claims to come from the same version.

To vendor a package:

  1. 1.
    clone the source to your local machine
  2. 2.
    mark it as a private package
  3. 3.
    publish it to OnePub
  4. 4.
    have your colleagues update their dependencies to use the vendored version of the package.
  5. 5.
    clone the source
git clone <repo>
2. mark the package as private
cd packagedir
onepub pub private enable
3. publish to OnePub
dart pub publish
4. update packages to use the vendored package
cd otherpackage
onepub pub add <vendored package>