10 Popular Go Libraries for Package & Dependency Management

In today's post we will learn about 10 Popular Go Libraries for Package & Dependency Management.

What is dependency management?

Dependency management is the process of managing all of these interrelated tasks and resources to ensure that your overall project completes successfully, on time, and on budget. When there are dependencies that need to be managed between projects, it's referred to as project interdependency management.

Table of contents:

  • Glide - Manage your golang vendor and vendored packages with ease. Inspired by tools like Maven, Bundler, and Pip.
  • Godep - dependency tool for go, godep helps build packages reproducibly by fixing their dependencies.
  • Gom - Go Manager - bundle for go.
  • Goop - Simple dependency manager for Go (golang), inspired by Bundler.
  • Gop - Build and manage your Go applications out of GOPATH.
  • Gopm - Go Package Manager.
  • MVN-golang - Plugin that provides way for auto-loading of Golang SDK, dependency management and start build environment in Maven project infrastructure.
  • Gpm - Barebones dependency manager for Go.
  • Johnny-deps - Minimal dependency version using Git.
  • Modgv - Converts 'go mod graph' output into Graphviz's DOT language.

1 - Glide:

Manage your golang vendor and vendored packages with ease. Inspired by tools like Maven, Bundler, and Pip.

Are you used to tools such as Cargo, npm, Composer, Nuget, Pip, Maven, Bundler, or other modern package managers? If so, Glide is the comparable Go tool.

Manage your vendor and vendored packages with ease. Glide is a tool for managing the vendor directory within a Go package. This feature, first introduced in Go 1.5, allows each package to have a vendor directory containing dependent packages for the project. These vendor packages can be installed by a tool (e.g. glide), similar to go get or they can be vendored and distributed with the package.

Go Modules

The Go community is now using Go Modules to handle dependencies. Please consider using that instead of Glide. Glide is now mostly unmaintained.

Features

  • Ease dependency management
  • Support versioning packages including Semantic Versioning 2.0.0 support. Any constraint the github.com/Masterminds/semver package can parse can be used.
  • Support aliasing packages (e.g. for working with github forks)
  • Remove the need for munging import statements
  • Work with all of the go tools
  • Support the VCS tools that Go supports:
    • git
    • bzr
    • hg
    • svn
  • Support custom local and global plugins (see docs/plugins.md)
  • Repository caching and data caching for improved performance.
  • Flatten dependencies resolving version differences and avoiding the inclusion of a package multiple times.
  • Manage and install dependencies on-demand or vendored in your version control system.

How It Works

Glide scans the source code of your application or library to determine the needed dependencies. To determine the versions and locations (such as aliases for forks) Glide reads a glide.yaml file with the rules. With this information Glide retrieves needed dependencies.

When a dependent package is encountered its imports are scanned to determine dependencies of dependencies (transitive dependencies). If the dependent project contains a glide.yaml file that information is used to help determine the dependency rules when fetching from a location or version to use. Configuration from Godep, GB, GOM, and GPM is also imported.

The dependencies are exported to the vendor/ directory where the go tools can find and use them. A glide.lock file is generated containing all the dependencies, including transitive ones.

The glide init command can be use to setup a new project, glide update regenerates the dependency versions using scanning and rules, and glide install will install the versions listed in the glide.lock file, skipping scanning, unless the glide.lock file is not found in which case it will perform an update.

A project is structured like this:

- $GOPATH/src/myProject (Your project)
  |
  |-- glide.yaml
  |
  |-- glide.lock
  |
  |-- main.go (Your main go code can live here)
  |
  |-- mySubpackage (You can create your own subpackages, too)
  |    |
  |    |-- foo.go
  |
  |-- vendor
       |-- github.com
            |
            |-- Masterminds
                  |
                  |-- ... etc.

Take a look at the Glide source code to see this philosophy in action.

Install

The easiest way to install the latest release on Mac or Linux is with the following script:

curl https://glide.sh/get | sh

On Mac OS X you can also install the latest release via Homebrew:

$ brew install glide

On Ubuntu Precise (12.04), Trusty (14.04), Wily (15.10) or Xenial (16.04) you can install from our PPA:

sudo add-apt-repository ppa:masterminds/glide && sudo apt-get update
sudo apt-get install glide

On Ubuntu Zesty (17.04) the package is called golang-glide.

Binary packages are available for Mac, Linux and Windows.

For a development version it is also possible to go get github.com/Masterminds/glide.

To build from source you can:

  1. Clone this repository into $GOPATH/src/github.com/Masterminds/glide and change directory into it
  2. If you are using Go 1.5 ensure the environment variable GO15VENDOREXPERIMENT is set, for example by running export GO15VENDOREXPERIMENT=1. In Go 1.6 it is enabled by default and in Go 1.7 it is always enabled without the ability to turn it off.
  3. Run make build

This will leave you with ./glide, which you can put in your $PATH if you'd like. (You can also take a look at make install to install for you.)

The Glide repo has now been configured to use glide to manage itself, too.

View on Github

2 - Godep:

Dependency tool for go, godep helps build packages reproducibly by fixing their dependencies.

Golang Dep

The Go community now has the dep project to manage dependencies. Please consider trying to migrate from Godep to dep. If there is an issue preventing you from migrating please file an issue with dep so the problem can be corrected. Godep will continue to be supported for some time but is considered to be in a state of support rather than active feature development.

Install

go get github.com/tools/godep

How to use godep with a new project

Assuming you've got everything working already, so you can build your project with go install and test it with go test, it's one command to start using:

godep save

This will save a list of dependencies to the file Godeps/Godeps.json and copy their source code into vendor/ (or Godeps/_workspace/ when using older versions of Go). Godep does not copy:

  • files from source repositories that are not tracked in version control.
  • *_test.go files.
  • testdata directories.
  • files outside of the go packages.

Godep does not process the imports of .go files with either the ignore or appengine build tags.

Test files and testdata directories can be saved by adding -t.

Read over the contents of vendor/ and make sure it looks reasonable. Then commit the Godeps/ and vendor/ directories to version control.

The deprecated -r flag

For older versions of Go, the -r flag tells save to automatically rewrite package import paths. This allows your code to refer directly to the copied dependencies in Godeps/_workspace. So, a package C that depends on package D will actually import C/Godeps/_workspace/src/D. This makes C's repo self-contained and causes go get to build C with the right version of all dependencies.

If you don't use -r, when using older version of Go, then in order to use the fixed dependencies and get reproducible builds, you must make sure that every time you run a Go-related command, you wrap it in one of these two ways:

  • If the command you are running is just go, run it as godep go ..., e.g. godep go install -v ./...
  • When using a different command, set your $GOPATH using godep path as described below.

-r isn't necessary with go1.6+ and isn't allowed.

View on Github

3 - Gom: 

Go Manager - bundle for go.

Why

The go get command is useful. But we want to fix the problem where package versions are different from the latest update. Are you going to do go get -tags=1.1 ..., go get -tag=0.3 for each of them? We want to freeze package version. Ruby's bundle is awesome.

Installation

go get github.com/mattn/gom

Gomfile

gom 'github.com/mattn/go-runewidth', :tag => 'go1'
gom 'github.com/mattn/go-scan', :commit => 'ecb144fb1f2848a24ebfdadf8e64380406d87206'
gom 'github.com/daviddengcn/go-colortext'
gom 'github.com/mattn/go-ole', :goos => 'windows'

# Execute only in the "test" environment.
group :test do
    gom 'github.com/mattn/go-sqlite3'
end

# Execute only for the "custom_group" group.
group :custom_group do
    gom 'github.com/golang/lint/golint'
end

By default gom install install all packages, except those in the listed groups. You can install packages from groups based on the environment using flags (development, test & production) : gom -test install

Custom groups my be specified using the -groups flag : gom -test -groups=custom_group,special install

Usage

Create _vendor directory and bundle packages into it

gom install

Build on current directory with _vendor packages

gom build

Run tests on current directory with _vendor packages

gom test

Generate .travis.yml that uses gom test

gom gen travis-yml

You can always change the name relative to the current $GOPATH directory using an environment variable: GOM_VENDOR_NAME

$ # to use a regular $GOPATH/src folder you should specify GOM_VENDOR_NAME equal '.'
$ GOM_VENDOR_NAME=. gom <command>

View on Github

4 - Goop: 

Simple dependency manager for Go (golang), inspired by Bundler.

A dependency manager for Go (golang), inspired by Bundler. It is different from other dependency managers in that it does not force you to mess with your GOPATH.

Getting Started

Install Goop: go get github.com/nitrous-io/goop

Create Goopfile. Revision reference (e.g. Git SHA hash) is optional, but recommended. Prefix hash with #. (This is to futureproof the file format.)

Example:

github.com/mattn/go-sqlite3
github.com/gorilla/context #14f550f51af52180c2eefed15e5fd18d63c0a64a
github.com/dotcloud/docker/pkg/proxy #v1.0.1 // comment
github.com/gorilla/mux !git@github.com:nitrous-io/mux.git // override repo url

Run goop install. This will install packages inside a subdirectory called .vendor and create Goopfile.lock, recording exact versions used for each package and its dependencies. Subsequent goop install runs will ignore Goopfile and install the versions specified in Goopfile.lock. You should check this file in to your source version control. It's a good idea to add .vendor to your version control system's ignore settings (e.g. .gitignore).

Run commands using goop exec (e.g. goop exec make). This will execute your command in an environment that has correct GOPATH and PATH set.

Go commands can be run without the exec keyword (e.g. goop go test).

Other commands

Run goop update to ignore an existing Goopfile.lock, and update to latest versions of packages (as specified in Goopfile).

Running eval $(goop env) will modify GOPATH and PATH in current shell session, allowing you to run commands without goop exec.

Caveat

Goop currently only supports Git and Mercurial. This should be fine for 99% of the cases, but you are more than welcome to make a pull request that adds support for Subversion and Bazaar.

View on Github

5 - Gop:

Build and manage your Go applications out of GOPATH.

GOP is a project manangement tool for building your golang applications out of global GOPATH. In fact gop will keep both global GOPATH and every project GOPATH. But that means your project will not go-getable. Of course, GOP itself is go-getable. GOP copy all denpendencies from global GOPATH to your project's src/vendor directory and all application's sources are also in src directory.

A normal process using gop is below:

git clone xxx@mydata.com:bac/aaa.git
cd aaa
gop ensure -g
gop build
gop test

Features

  • GOPATH compitable
  • Multiple build targets support
  • Put your projects out of global GOPATH

Installation

Please ensure you have installed the go command, GOP will invoke it on building or testing

go get github.com/lunny/gop

Directory structure

Every project should have a GOPATH directory structure and put a gop.yml int the root directory. This is an example project's directory tree.

<project root>
├── gop.yml
├── bin
├── doc
└── src
    ├── main
    │   └── main.go
    ├── models
    │   └── models.go
    ├── routes
    │   └── routes.go
    └── vendor
        └── github.com
            ├── go-xorm
            │   ├── builder
            │   ├── core
            │   └── xorm
            └── lunny
                ├── log
                └── tango

View on Github

6 - Gopm:

Go Package Manager.

Gopm (Go Package Manager) is a Go package manage and build tool for Go.

Requirements

  • Go development environment: >= go1.2

Installation

Install from source code

go get -u github.com/gpmgo/gopm

The executable will be produced under $GOPATH/bin in your file system; for global use purpose, we recommend you to add this path into your PATH environment variable.

Features

  • No requirement for installing any version control system tool like git or hg in order to download packages.
  • Download, install or build your packages with specific revisions.
  • When building programs with gopm build or gopm install, everything just happens in its own GOPATH and does not bother anything you've done (unless you told it to).
  • Can put your Go projects anywhere you want (through .gopmfile).

Commands

NAME:
   Gopm - Go Package Manager

USAGE:
   Gopm [global options] command [command options] [arguments...]

COMMANDS:
   list		list all dependencies of current project
   gen		generate a gopmfile for current Go project
   get		fetch remote package(s) and dependencies
   bin		download and link dependencies and build binary
   config	configure gopm settings
   run		link dependencies and go run
   test		link dependencies and go test
   build	link dependencies and go build
   install	link dependencies and go install
   clean	clean all temporary files
   update	check and update gopm resources including itself
   help, h	Shows a list of commands or help for one command

GLOBAL OPTIONS:
   --noterm, -n		disable color output
   --strict, -s		strict mode
   --debug, -d		debug mode
   --help, -h		show help
   --version, -v	print the version

View on Github

7 - MVN-golang: 

Plugin that provides way for auto-loading of Golang SDK, dependency management and start build environment in Maven project infrastructure.

GO start!

Taste Go in just two commands!

mvn archetype:generate -B -DarchetypeGroupId=com.igormaznitsa -DarchetypeArtifactId=mvn-golang-hello -DarchetypeVersion=2.3.10 -DgroupId=com.go.test -DartifactId=gohello -Dversion=1.0-SNAPSHOT
mvn -f ./gohello/pom.xml package

The First command in th snippet above generates a maven project with some test files and the second command builds the project. Also you can take a look at the example Hello world project using the plugin

If you want to generate a multi-module project, then you can use such snippet

mvn archetype:generate -B -DarchetypeGroupId=com.igormaznitsa -DarchetypeArtifactId=mvn-golang-hello-multi -DarchetypeVersion=2.3.10 -DgroupId=com.go.test -DartifactId=gohello-multi -Dversion=1.0-SNAPSHOT

Introduction

The Plug-in just wraps Golang tool-chain and allows to use strong maven based infrastructure to build Golang projects. It also can automatically download needed Golang SDK from the main server and tune needed version of packets for their branch, tag or revisions. Because a Golang project in the case is formed as just maven project, it is possible to work with it in any Java IDE which supports Maven. mvn-golang-wrapper

How it works

On start the plug-in makes below steps:

  • analyzing the current platform to generate needed distributive name (it can be defined directly through properties)
  • check that needed Golang SDK is already cached, if it is not cached then needed SDK will be loaded and unpacked from the main Golang SDK site
  • execute needed go lang tool bin/go with defined command, the source folder will be set as current folder
  • all folders of the project which are visible for maven (source folder, test folder, resource folders and test resource folders) are archived in ZIP file and the file is saved as a maven artifact into local maven repository (or remote maven repository). The generated ZIP artifact also contains information about dependencies which can be recognized by the plugin. In opposite to Java, Golang produces platform-dependent artifacts so that it doesn't make sense to share them through maven central but only resources and sources.

How to build

Because it is maven plugin, to build the plugin just use

mvn clean install -Pplugin

To save time, examples excluded from the main build process and activated through special profile

mvn clean install -Pexamples

View on Github

8 - Gpm:

Barebones dependency manager for Go.

Go Package Manager (or gpm, for short) is a tool that helps achieve reproducible builds for Go applications by specifying the revision of each external Go package that the application depends on.

Being simple and unobstrusive are some of the most important design choices for gpm: go get already provides a way to fetch dependencies, and relies on versions control systems like Git to do it, gpm adds the additional step of setting each dependency repo to the desired revision, neither Go or your application even know about any of this happening, it just works.

To achieve this, gpm uses a manifest file which is assumed to be called Godeps (although you can name it however you want), running gpm fetches all dependencies and ensures each is set to a specified version, down to revision level.

Basic usage

For a given project, running gpm in the directory containing the Godeps file is enough to make sure dependencies in the file are fetched and set to the correct revision.

However, if you share your GOPATH with other projects running gpm each time can get old, my solution for that is to isolate dependencies by manipulating the GOPATH, see the workspaces section for details.

You can see gpm in action under this workflow in the following gif:

sample gpm usage

Installation options

In OSX with Homebrew

$ brew install gpm

In Arch Linux - AUR

$ yaourt -S go-gpm

or

$ packer -S go-gpm

Caveat: you'll use go-gpm instead of just gpm in the command line, as there is a general purpose linux package under that name already.

View on Github

9 - Johnny-deps:

Minimal dependency version using Git.

Johnny Deps is a small tool from VividCortex that provides minimalistic dependency versioning for Go repositories using Git. Its primary purpose is to help create reproducible builds when many import paths in various repositories are required to build an application. It's based on a Perl script that provides subcommands for retrieving or building a project, or updating a dependencies file (called Godeps), listing first-level imports for a project.

Getting started

Install Johnny Deps by cloning the project's Github repository and running the provided scripts, like this:

git clone https://github.com/VividCortex/johnny-deps.git
cd johnny-deps
./configure --prefix=/your/path
make install

The --prefix option to configure is not mandatory; it defaults to /usr/local if not provided (but you'd have to install as root in that case). The binary will end up at the bin subdirectory, under the prefix you choose; make sure you have that location specified in your PATH.

Note that Perl is required, although that's probably provided by your system already. Also Go, Git and (if you're using makefiles) Make.

Dependencies

Johnny Deps is all about project dependencies. Each project should have a file called Godeps at its root, listing the full set of first-level dependencies; i.e., all repositories with Go packages imported directly by this project. The file may be omitted when empty and looks like this:

github.com/VividCortex/godaemon 2fdf3f9fa715a998e834f09e07a8070d9046bcfd
github.com/VividCortex/log 1ffbbe58b5cf1bcfd7a80059dd339764cc1e3bff
github.com/VividCortex/mysql f82b14f1073afd7cb41fc8eb52673d78f481922e

The first column identifies the dependency. The second is the commit identifier for the exact revision the current project depends upon. You can use any identifier Git would accept to checkout, including abbreviated commits, tags and branches. Note, however, that the use of branches is discouraged, cause it leads to non-reproducible builds as the tip of the branch moves forward.

Introducing the tool

jd is Johnny Deps' main binary. It's a command line tool to retrieve projects from Github, check dependencies, reposition local working copies according to each project's settings, building and updating. It accepts subcommands much like go or git do:

jd [global-options] [command] [options] [project]

Global options apply to all commands. Some allow you to change the external tools that are used (go, git and make) in case you don't have them in your path, or otherwise want to use a different version. There's also a -v option to increase verbosity, that you can provide twice for extra effect. (Note that the tool runs silently by default, only displaying errors, if any.)

It's worth noting that all parameters are optional. If you don't specify a command, it will default to build (see "Building" below). If you don't specify a project, jd will try to infer the project based on your current working path, and your setting for GOPATH. If you're in a subdirectory of any of the GOPATH components, and you're also in a Git working tree, jd would be happy to fill up the project for you.

When in doubt, check jd help.

View on Github

10 - Modgv:

Converts 'go mod graph' output into Graphviz's DOT language.

Converts 'go mod graph' output into GraphViz's DOT language.

  • takes no options or arguments
  • it reads the output generated by “go mod graph” on stdin
  • generates a DOT language and writes to stdout

Usage:

go mod graph | modgv | dot -Tpng -o graph.png

For each module:

  • the node representing the greatest version (i.e., the version chosen by Go's MVS algorithm) is colored green
  • other nodes, which aren't in the final build list, are colored grey

Installation

go get github.com/lucasepe/modgv/modgv

Here 👉 https://graphviz.gitlab.io/download/ how to install GraphViz for your OS.

Sample output (PNG)

go mod graph | modgv | dot -Tpng -o graph.png


Sample output (PDF with clickable links to module docs)

go mod graph | modgv | dot -Tps2 -o graph.ps
ps2pdf graph.ps graph.pdf

View on Github

Thank you for following this article.

Related videos:

Learning Golang: Dependencies, Modules and How to manage Packages

#go #golang #dependency #management 

10 Popular Go Libraries for Package & Dependency Management
Leonard  Paucek

Leonard Paucek

1653393600

Lerna: A Tool For Managing JavaScript Projects with Multiple Packages.

Important note: this project is changing stewardship to Nrwl! Your favorite tool will continue to live on. Stay tuned for updates and soon a project roadmap!

A tool for managing JavaScript projects with multiple packages. 

About

Splitting up large codebases into separate independently versioned packages is extremely useful for code sharing. However, making changes across many repositories is messy and difficult to track, and testing across repositories becomes complicated very quickly.

To solve these (and many other) problems, some projects will organize their codebases into multi-package repositories (sometimes called monorepos). Projects like Babel, React, Angular, Ember, Meteor, Jest, and many others develop all of their packages within a single repository.

Lerna is a tool that optimizes the workflow around managing multi-package repositories with git and npm.

Lerna can also reduce the time and space requirements for numerous copies of packages in development and build environments - normally a downside of dividing a project into many separate NPM packages. See the hoist documentation for details.

What does a Lerna repo look like?

There's actually very little to it. You have a file structure that looks like this:

my-lerna-repo/
  package.json
  packages/
    package-1/
      package.json
    package-2/
      package.json

What can Lerna do?

The two primary commands in Lerna are lerna bootstrap and lerna publish.

bootstrap will link dependencies in the repo together. publish will help publish any updated packages.

What can't Lerna do?

Lerna is not a deployment tool for serverless monorepos. Hoisting might be incompatible with traditional serverless monorepo deployment techniques.

Getting Started

The instructions below are for Lerna 3.x. We recommend using it instead of 2.x for a new Lerna project.

Let's start by installing Lerna as a dev dependency of your project with npm.

$ mkdir lerna-repo && cd $_
$ npx lerna init

This will create a lerna.json configuration file as well as a packages folder, so your folder should now look like this:

lerna-repo/
  packages/
  package.json
  lerna.json

How It Works

Lerna allows you to manage your project using one of two modes: Fixed or Independent.

Fixed/Locked mode (default)

Fixed mode Lerna projects operate on a single version line. The version is kept in the lerna.json file at the root of your project under the version key. When you run lerna publish, if a module has been updated since the last time a release was made, it will be updated to the new version you're releasing. This means that you only publish a new version of a package when you need to.

Note: If you have a major version zero, all updates are considered breaking. Because of that, running lerna publish with a major version zero and choosing any non-prerelease version number will cause new versions to be published for all packages, even if not all packages have changed since the last release.

This is the mode that Babel is currently using. Use this if you want to automatically tie all package versions together. One issue with this approach is that a major change in any package will result in all packages having a new major version.

Independent mode

lerna init --independent

Independent mode Lerna projects allows maintainers to increment package versions independently of each other. Each time you publish, you will get a prompt for each package that has changed to specify if it's a patch, minor, major or custom change.

Independent mode allows you to more specifically update versions for each package and makes sense for a group of components. Combining this mode with something like semantic-release would make it less painful. (There is work on this already at atlassian/lerna-semantic-release).

Set the version key in lerna.json to independent to run in independent mode.

Troubleshooting

If you encounter any issues while using Lerna please check out our Troubleshooting document where you might find the answer to your problem.

Frequently asked questions

See FAQ.md.

Concepts

Lerna will log to a lerna-debug.log file (same as npm-debug.log) when it encounters an error running a command.

Lerna also has support for scoped packages.

Run lerna --help to see all available commands and options.

lerna.json

{
  "version": "1.1.3",
  "npmClient": "npm",
  "command": {
    "publish": {
      "ignoreChanges": ["ignored-file", "*.md"],
      "message": "chore(release): publish",
      "registry": "https://npm.pkg.github.com"
    },
    "bootstrap": {
      "ignore": "component-*",
      "npmClientArgs": ["--no-package-lock"]
    }
  },
  "packages": ["packages/*"]
}
  • version: the current version of the repository.
  • npmClient: an option to specify a specific client to run commands with (this can also be specified on a per command basis). Change to "yarn" to run all commands with yarn. Defaults to "npm".
  • command.publish.ignoreChanges: an array of globs that won't be included in lerna changed/publish. Use this to prevent publishing a new version unnecessarily for changes, such as fixing a README.md typo.
  • command.publish.message: a custom commit message when performing version updates for publication. See @lerna/version for more details.
  • command.publish.registry: use it to set a custom registry url to publish to instead of npmjs.org, you must already be authenticated if required.
  • command.bootstrap.ignore: an array of globs that won't be bootstrapped when running the lerna bootstrap command.
  • command.bootstrap.npmClientArgs: array of strings that will be passed as arguments directly to npm install during the lerna bootstrap command.
  • command.bootstrap.scope: an array of globs that restricts which packages will be bootstrapped when running the lerna bootstrap command.
  • packages: Array of globs to use as package locations.

The packages config in lerna.json is a list of globs that match directories containing a package.json, which is how lerna recognizes "leaf" packages (vs the "root" package.json, which is intended to manage the dev dependencies and scripts for the entire repo).

By default, lerna initializes the packages list as ["packages/*"], but you can also use another directory such as ["modules/*"], or ["package1", "package2"]. The globs defined are relative to the directory that lerna.json lives in, which is usually the repository root. The only restriction is that you can't directly nest package locations, but this is a restriction shared by "normal" npm packages as well.

For example, ["packages/*", "src/**"] matches this tree:

packages/
├── foo-pkg
│   └── package.json
├── bar-pkg
│   └── package.json
├── baz-pkg
│   └── package.json
└── qux-pkg
    └── package.json
src/
├── admin
│   ├── my-app
│   │   └── package.json
│   ├── stuff
│   │   └── package.json
│   └── things
│       └── package.json
├── profile
│   └── more-things
│       └── package.json
├── property
│   ├── more-stuff
│   │   └── package.json
│   └── other-things
│       └── package.json
└── upload
    └── other-stuff
        └── package.json

Locating leaf packages under packages/* is considered a "best-practice", but is not a requirement for using Lerna.

Legacy Fields

Some lerna.json fields are no longer in use. Those of note include:

Common devDependencies

Most devDependencies can be pulled up to the root of a Lerna repo with lerna link convert

The above command will automatically hoist things and use relative file: specifiers.

Hoisting has a few benefits:

  • All packages use the same version of a given dependency
  • Can keep dependencies at the root up-to-date with an automated tool such as Snyk
  • Dependency installation time is reduced
  • Less storage is needed

Note that devDependencies providing "binary" executables that are used by npm scripts still need to be installed directly in each package where they're used.

For example the nsp dependency is necessary in this case for lerna run nsp (and npm run nsp within the package's directory) to work correctly:

{
  "scripts": {
    "nsp": "nsp"
  },
  "devDependencies": {
    "nsp": "^2.3.3"
  }
}

Git Hosted Dependencies

Lerna allows target versions of local dependent packages to be written as a git remote url with a committish (e.g., #v1.0.0 or #semver:^1.0.0) instead of the normal numeric version range. This allows packages to be distributed via git repositories when packages must be private and a private npm registry is not desired.

Please note that lerna does not perform the actual splitting of git history into the separate read-only repositories. This is the responsibility of the user. (See this comment for implementation details)

// packages/pkg-1/package.json
{
  name: "pkg-1",
  version: "1.0.0",
  dependencies: {
    "pkg-2": "github:example-user/pkg-2#v1.0.0"
  }
}

// packages/pkg-2/package.json
{
  name: "pkg-2",
  version: "1.0.0"
}

In the example above:

  • lerna bootstrap will properly symlink pkg-2 into pkg-1.
  • lerna publish will update the committish (#v1.0.0) in pkg-1 when pkg-2 changes.

README Badge

Using Lerna? Add a README badge to show it off: lerna

[![lerna](https://img.shields.io/badge/maintained%20with-lerna-cc00ff.svg)](https://lerna.js.org/)

Wizard

If you prefer some guidance for cli (in case you're about to start using lerna or introducing it to a new team), you might like lerna-wizard. It will lead you through a series of well-defined steps:

lerna-wizard demo image


Author: lerna
Source Code: https://github.com/lerna/lerna
License: MIT license

#react-native #react 

Lerna: A Tool For Managing JavaScript Projects with Multiple Packages.
Waylon  Bruen

Waylon Bruen

1651188000

Goop: A Simple Dependency Manager for Go (golang), inspired By Bundler

Goop

A dependency manager for Go (golang), inspired by Bundler. It is different from other dependency managers in that it does not force you to mess with your GOPATH.

Getting Started

Install Goop: go get github.com/nitrous-io/goop

Create Goopfile. Revision reference (e.g. Git SHA hash) is optional, but recommended. Prefix hash with #. (This is to futureproof the file format.)

Example:

github.com/mattn/go-sqlite3
github.com/gorilla/context #14f550f51af52180c2eefed15e5fd18d63c0a64a
github.com/dotcloud/docker/pkg/proxy #v1.0.1 // comment
github.com/gorilla/mux !git@github.com:nitrous-io/mux.git // override repo url

Run goop install. This will install packages inside a subdirectory called .vendor and create Goopfile.lock, recording exact versions used for each package and its dependencies. Subsequent goop install runs will ignore Goopfile and install the versions specified in Goopfile.lock. You should check this file in to your source version control. It's a good idea to add .vendor to your version control system's ignore settings (e.g. .gitignore).

Run commands using goop exec (e.g. goop exec make). This will execute your command in an environment that has correct GOPATH and PATH set.

Go commands can be run without the exec keyword (e.g. goop go test).

Other commands

Run goop update to ignore an existing Goopfile.lock, and update to latest versions of packages (as specified in Goopfile).

Running eval $(goop env) will modify GOPATH and PATH in current shell session, allowing you to run commands without goop exec.

Caveat

Goop currently only supports Git and Mercurial. This should be fine for 99% of the cases, but you are more than welcome to make a pull request that adds support for Subversion and Bazaar.


Work on awesome golang projects, like Goop, at Nitrous.IO

Copyright (c) 2014 Irrational Industries, Inc. d.b.a. Nitrous.IO.

Author: Petejkim
Source Code: https://github.com/petejkim/goop 
License: MIT License

#go #golang 

Goop: A Simple Dependency Manager for Go (golang), inspired By Bundler
Gordon  Taylor

Gordon Taylor

1650462483

Lerna: A tool for managing JavaScript projects with multiple packages

A tool for managing JavaScript projects with multiple packages.

About

Splitting up large codebases into separate independently versioned packages is extremely useful for code sharing. However, making changes across many repositories is messy and difficult to track, and testing across repositories becomes complicated very quickly.

To solve these (and many other) problems, some projects will organize their codebases into multi-package repositories (sometimes called monorepos). Projects like Babel, React, Angular, Ember, Meteor, Jest, and many others develop all of their packages within a single repository.

Lerna is a tool that optimizes the workflow around managing multi-package repositories with git and npm.

Lerna can also reduce the time and space requirements for numerous copies of packages in development and build environments - normally a downside of dividing a project into many separate NPM packages. See the hoist documentation for details.

What does a Lerna repo look like?

There's actually very little to it. You have a file structure that looks like this:

my-lerna-repo/
  package.json
  packages/
    package-1/
      package.json
    package-2/
      package.json

What can Lerna do?

The two primary commands in Lerna are lerna bootstrap and lerna publish.

bootstrap will link dependencies in the repo together. publish will help publish any updated packages.

What can't Lerna do?

Lerna is not a deployment tool for serverless monorepos. Hoisting might be incompatible with traditional serverless monorepo deployment techniques.

Getting Started

The instructions below are for Lerna 3.x. We recommend using it instead of 2.x for a new Lerna project.

Let's start by installing Lerna as a dev dependency of your project with npm.

$ mkdir lerna-repo && cd $_
$ npx lerna init

This will create a lerna.json configuration file as well as a packages folder, so your folder should now look like this:

lerna-repo/
  packages/
  package.json
  lerna.json

How It Works

Lerna allows you to manage your project using one of two modes: Fixed or Independent.

Fixed/Locked mode (default)

Fixed mode Lerna projects operate on a single version line. The version is kept in the lerna.json file at the root of your project under the version key. When you run lerna publish, if a module has been updated since the last time a release was made, it will be updated to the new version you're releasing. This means that you only publish a new version of a package when you need to.

Note: If you have a major version zero, all updates are considered breaking. Because of that, running lerna publish with a major version zero and choosing any non-prerelease version number will cause new versions to be published for all packages, even if not all packages have changed since the last release.

This is the mode that Babel is currently using. Use this if you want to automatically tie all package versions together. One issue with this approach is that a major change in any package will result in all packages having a new major version.

Independent mode

lerna init --independent

Independent mode Lerna projects allows maintainers to increment package versions independently of each other. Each time you publish, you will get a prompt for each package that has changed to specify if it's a patch, minor, major or custom change.

Independent mode allows you to more specifically update versions for each package and makes sense for a group of components. Combining this mode with something like semantic-release would make it less painful. (There is work on this already at atlassian/lerna-semantic-release).

Set the version key in lerna.json to independent to run in independent mode.

Troubleshooting

If you encounter any issues while using Lerna please check out our Troubleshooting document where you might find the answer to your problem.

Frequently asked questions

See FAQ.md.

Concepts

Lerna will log to a lerna-debug.log file (same as npm-debug.log) when it encounters an error running a command.

Lerna also has support for scoped packages.

Run lerna --help to see all available commands and options.

lerna.json

{
  "version": "1.1.3",
  "npmClient": "npm",
  "command": {
    "publish": {
      "ignoreChanges": ["ignored-file", "*.md"],
      "message": "chore(release): publish",
      "registry": "https://npm.pkg.github.com"
    },
    "bootstrap": {
      "ignore": "component-*",
      "npmClientArgs": ["--no-package-lock"]
    }
  },
  "packages": ["packages/*"]
}
  • version: the current version of the repository.
  • npmClient: an option to specify a specific client to run commands with (this can also be specified on a per command basis). Change to "yarn" to run all commands with yarn. Defaults to "npm".
  • command.publish.ignoreChanges: an array of globs that won't be included in lerna changed/publish. Use this to prevent publishing a new version unnecessarily for changes, such as fixing a README.md typo.
  • command.publish.message: a custom commit message when performing version updates for publication. See @lerna/version for more details.
  • command.publish.registry: use it to set a custom registry url to publish to instead of npmjs.org, you must already be authenticated if required.
  • command.bootstrap.ignore: an array of globs that won't be bootstrapped when running the lerna bootstrap command.
  • command.bootstrap.npmClientArgs: array of strings that will be passed as arguments directly to npm install during the lerna bootstrap command.
  • command.bootstrap.scope: an array of globs that restricts which packages will be bootstrapped when running the lerna bootstrap command.
  • packages: Array of globs to use as package locations.

The packages config in lerna.json is a list of globs that match directories containing a package.json, which is how lerna recognizes "leaf" packages (vs the "root" package.json, which is intended to manage the dev dependencies and scripts for the entire repo).

By default, lerna initializes the packages list as ["packages/*"], but you can also use another directory such as ["modules/*"], or ["package1", "package2"]. The globs defined are relative to the directory that lerna.json lives in, which is usually the repository root. The only restriction is that you can't directly nest package locations, but this is a restriction shared by "normal" npm packages as well.

For example, ["packages/*", "src/**"] matches this tree:

packages/
├── foo-pkg
│   └── package.json
├── bar-pkg
│   └── package.json
├── baz-pkg
│   └── package.json
└── qux-pkg
    └── package.json
src/
├── admin
│   ├── my-app
│   │   └── package.json
│   ├── stuff
│   │   └── package.json
│   └── things
│       └── package.json
├── profile
│   └── more-things
│       └── package.json
├── property
│   ├── more-stuff
│   │   └── package.json
│   └── other-things
│       └── package.json
└── upload
    └── other-stuff
        └── package.json

Locating leaf packages under packages/* is considered a "best-practice", but is not a requirement for using Lerna.

Legacy Fields

Some lerna.json fields are no longer in use. Those of note include:

Common devDependencies

Most devDependencies can be pulled up to the root of a Lerna repo with lerna link convert

The above command will automatically hoist things and use relative file: specifiers.

Hoisting has a few benefits:

  • All packages use the same version of a given dependency
  • Can keep dependencies at the root up-to-date with an automated tool such as Snyk
  • Dependency installation time is reduced
  • Less storage is needed

Note that devDependencies providing "binary" executables that are used by npm scripts still need to be installed directly in each package where they're used.

For example the nsp dependency is necessary in this case for lerna run nsp (and npm run nsp within the package's directory) to work correctly:

{
  "scripts": {
    "nsp": "nsp"
  },
  "devDependencies": {
    "nsp": "^2.3.3"
  }
}

Git Hosted Dependencies

Lerna allows target versions of local dependent packages to be written as a git remote url with a committish (e.g., #v1.0.0 or #semver:^1.0.0) instead of the normal numeric version range. This allows packages to be distributed via git repositories when packages must be private and a private npm registry is not desired.

Please note that lerna does not perform the actual splitting of git history into the separate read-only repositories. This is the responsibility of the user. (See this comment for implementation details)

// packages/pkg-1/package.json
{
  name: "pkg-1",
  version: "1.0.0",
  dependencies: {
    "pkg-2": "github:example-user/pkg-2#v1.0.0"
  }
}

// packages/pkg-2/package.json
{
  name: "pkg-2",
  version: "1.0.0"
}

In the example above,

  • lerna bootstrap will properly symlink pkg-2 into pkg-1.
  • lerna publish will update the committish (#v1.0.0) in pkg-1 when pkg-2 changes.

README Badge

Using Lerna? Add a README badge to show it off: lerna

[![lerna](https://img.shields.io/badge/maintained%20with-lerna-cc00ff.svg)](https://lerna.js.org/)

Wizard

If you prefer some guidance for cli (in case you're about to start using lerna or introducing it to a new team), you might like lerna-wizard. It will lead you through a series of well-defined steps:

lerna-wizard demo image

Author: lerna
Source Code: https://github.com/lerna/lerna 
License: MIT License

#lerna #javascript #npm 

Lerna: A tool for managing JavaScript projects with multiple packages