digs-dev

Common development dependencies for digs.

Warning

This is an experiment.

What It Does

Provides common development requirements to digs and its minions.

Why It Does It

I have a fair amount of dotfiles, test fixtures and Grunt task files that are common to all packages in digsjs.

These files are necessary for development on our packages, but have nothing to do with production code.

I consulted with the folks @ npm on the best way to approach this problem, and this is the solution they suggested. If you have a better one, I'd love to hear it.

How It Works

Each package requiring digs-dev must have a prepublish script which will execute the install command of the digs-dev executable, like so:

$ cd path/to/some/digsjs-package
$ digs-dev install

In package.json, this is simply:

{ 
  "scripts": {
    "prepublish": "digs-dev install"
  }
}

The install command of the digs-dev executable does the following, as of this writing:

1. Scans all development dependencies (devDependencies) in the current directory's package.json, and compares them to its own. If anything is missing or out of date, the package is added or updated, respectively. If the current directory has a .git subdirectory, the --save-dev option is added to the npm call. This means if you happen to clone, say, digs-common, if the development deps are out-of-date, package.json will be in the "modified" state. package.json is not added to Git's index, but somebody (you?) is expected to commit the changes.
2. Symlinks a bunch of dotfiles and configuration into the appropriate places. Example: Gruntfile.js. Another example: .eslintrc. All packages under the digsjs banner have the same Gruntfile.js and .eslintrc; they are just not under version control, except in this package.
3. Scans .gitignore for the symlinked files and adds an entry if not found. The same rule as in #1 applies; if digs-dev detects a .git folder, your working copy will be modified.

Any existing file which does not happen to be a symlink which digs-dev wants to overwrite will be skipped. That means packages can override these files simply by adding them to version control (and removing their entries from .gitignore).

The install command runs three other commands, corresponding to the above list, in series:

1. upgrade (digs-dev upgrade)
2. symlink (digs-dev symlink)
3. gitignore (digs-dev gitignore)

If you just want to re-run one of these, they are available.

Author

Christopher Hiller

License

MIT