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 pub.dev 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 pub.dev (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 pub.dev (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. clone the source to your local machine

2. mark it as a private package

3. publish it to OnePub

4. have your colleagues update their dependencies to use the vendored version of the package.

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>