duojs/duo — pull request #298 by ianstormtaylor (2014-09-07 22:33:57+00:00)
Title: change the accessor logic to make it more consistent

Second cleanup-y pull request here. _You'll want to merge the lots-of-small-changes style one from #297 first just because I didn't want them to conflict later._

This one is about bringing consistency to the way that Duo exposes its settings in the Javascript API. Basically before we had a handful of different ways the accessors worked, with underscore-prefixed properties on the instance, and this paves over all of that with simple methods for each. The commit is a little big, but I wanted to change them all at once so that we can see what it feels like with the cleaner version everywhere. Here's the changes:

##### `copy` and `development`

Changed to make them get and set, and not have logic around defaulting to true when invoked with undefined (since that gets now). I figured that all of the examples use the `.copy(true)` syntax instead of `.copy()` syntax anyways since it's clearer, so better to just have one way of doing things there.

##### `token`, `global` and `concurrency`

Just cleaned them up to make them the same style, but they were already getter-setters.

##### `manifest`

Changed the series of manifest options on the instance to a single `.manifest(name)` method that sets the manifest name. I think we really shouldn't even need this, but I didn't want to hardcode the value everywhere since work was done to make that not happen, so this seemed good.

##### `buildTo` and `installTo`

Renamed these from `assets` and `install` to make them much clearer when used, and made them return the relative path as getters. This change also goes along with a couple of other methods that make the getting part super easy:

##### `path`, `buildPath` and `installPath`

Add these convenience methods for resolving paths relative to `root`, `root/buildTo` and `root/installTo`, respectively. I was noticing that we were calculating these a lot in different places with `join`s and that some of the manifest properties from above were just conveniences since we didn't have these types of methods. This should make it easier for plugin authors to work with paths for the packages too.

##### `entry`

Changed the new `entry` method to combine the old `.entry(path)` and `.src(file, type)` methods. My logic here is that it's not the Javascript APIs responsibility to decipher the type of the source passed in, that should be handled in the command line where the standard in is first read. That change means we can just `switch` off `arguments.length` and we end up with a nice, single `.entry([path|source], [type])` method that will set the entry file given either set of values (or get with none).

##### `json`

Renamed the old `.manifest` property to be the getter-setter, and instead called that old property `.json`. And made the old `.json` method a simple closured convenience function since it wasn't really instance-specific.

---

Just to be clear, there are a series of backwards incompatible changes in this pull request, which I hope we can make since it cleans up the API a lot, and we're still under `1.0` and people haven't started relying on the Javascript API too much yet.

I tried to keep editing the tests to a minimum, so that we can be sure we don't have regressions, but if we merge this I will open another one that upgrades the testing for all of these new getter-setters methods, and for the path helpers.