Phrase dependency management about elliptical HOT 3 CLOSED

##Desired Implementation

Option 2, kinda.

Each phrase will look like this:

{
    name: 'thisPhrase',
    version: '0.3.2',
    dependencies: [
        require('lacona-phrase-simplePhrase'),
        require('lacona-phrase-anotherPhrase')
    ],
    extends: {
        'notAsCoolPhrase': '*'
    },
    precedes: {
        'someDumbPhrase': '2.3.x-4.x'
    },
    root: ...
}

So notice that with this configuration, dependencies are specified with their full grammars, but extends and precedes are only specified by name.

When a phrase's root property contains references to another phrase beyond the built-in 5, it will look for that phrase in and ONLY in the dependencies phrases. If it doesn't find it, it will throw a runtime error. All version management here is done entirely within package.json and npm.

However, extends and precedes effect the full lacona parser. Whenever any phrase is referenced called notAsCoolPhrase or someDumbPhrase and it matches the specified version, it will extend or precede it with thisPhrase.

The only confusing part here is versioning. You will notice that thisPhrase has a version, but it is completely independent of it's module's package.json. It still uses semver and it could be the same, but it by no means needs to. The reason for this is twofold:

1. There is no way to get the version of another module that is easily Browserifiable.
2. One module can contain many phrases, which should be able to be versioned independently.

To simplify things, the version property defaults to 0.0.0. The extends and precedes properties can be specified as a String or an Array. In that case, the version defaults to 0.0.0.

extends: 'notAsCoolPhrase' == ['notAsCoolPhrase'] == {notAsCoolPhrase: '0.0.0'}

That is to say, if you ignore versioning in both your extends/precedes properties and your version property, everything will work fine (until you make a breaking change). When you do make a breaking change, you can just call it 0.0.1 or 1.0.0 and users who did not specify a version will now need to specify one to refer to the new version.

Pros:

• Simple to implement
• Completely avoids dependency hell
• Allows basic users to avoid versioning altogether (For now, I believe this is an advantage)
• Automatically browserifiable
• Assuming that phrase authors follow semver, version-safe

Cons:

• Requires basic knowledge of node/npm in order to write a phrase
• Phrases that rely upon non-builtin phrases cannot be JSON files (they need to call require)
  • Doesn't matter too much, since language-splitting would encourage a root index.js anyways
• Somewhat confusing as each phrase now has two versions, a module version and a phrase version. A module version can change without a phrase version changing. Hopefully breaking changes don't happen in this way, but it is possible.

from elliptical.

Other con: name conflicts.

We'll just deal with that for now.

from elliptical.

Implemented with 5afc088

from elliptical.