joelpurra / bespoke-convenient

Convenient extension methods for building Bespoke.js plugins

Trending + "the simpsons"

Powered By GIPHY

bespoke-convenient's Issues

Allow for automatic dependency checking, per deck activation

Issue based on bespoke-secondary pull request #2, automatically run dependant plugins, by @markdalgleish.

Unfortunately, automatic loading/activation of dependencies in secondary would (potentially) break other plugins depending on convenient or indexfinger, such as jumpy and logbook. These dependencies may currently work anyways, by chance, but they are not prepared for multiple deck activations.

Dependency checking, activation and protection against multiple deck activations is something I could build into convenient, as all of my bespoke plugins depend on it. Maybe even a dependency graph, for proper load order. Then even convenient itself could conveniently be split to smaller parts.

Things sure get out of hand quick sometimes ;)

It's all fine and dandy for both convenient and indexfinger to be loaded as "automatic dependencies", as they don't accept any options, in their current versions. Just to keep it in mind, there's one future/bigger picture problem though - plugin options passed at activation time might conflict.

Plugin A, depending on somedependency:

bespoke.plugins.somedependency(deck,
  {
    custom: "smart non-default value"
  });

Plugin B, also depending on somedependency:

bespoke.plugins.somedependency(deck,
  {
    custom: "conflicting non-default value"
  });

Plugin C, also depending on somedependency, but using only default values.

bespoke.plugins.somedependency(deck);

I'm thinking of:

• Adding dependencies, and below dependency options, to var cv = convenient.builder(pluginName);
• Calculating per deck plugin activation order with a dependency graph.
• Letting plugins define themselves as allowed for automatic dependencies, or not.
• By default plugins would only be automatically activated once per deck; option for multiple activations.
• Allow plugins to define themselves to allow for either automatic option merging (including/excluding conflicting options), or custom per-plugin method option merging.

The per plugin option merging would allow for things like document level event listeners to be rewired, if necessary.

Thoughts, suggestions?

EPEERINVALID incompatibility with bespoke v1.x

npm throws the following error when trying to install:

♆ > npm i -D bespoke-jumpy
npm ERR! peerinvalid The package bespoke does not satisfy its siblings' peerDependencies requirements!
npm ERR! peerinvalid Peer [email protected] wants bespoke@^1.0.0
npm ERR! peerinvalid Peer [email protected] wants bespoke@^1.0.0
npm ERR! peerinvalid Peer [email protected] wants bespoke@~0.3.1
npm ERR! peerinvalid Peer [email protected] wants bespoke@^1.0.0
npm ERR! peerinvalid Peer [email protected] wants bespoke@~0.3.1
npm ERR! peerinvalid Peer [email protected] wants bespoke@^1.0.0-beta
npm ERR! peerinvalid Peer [email protected] wants bespoke@^1.0.0
npm ERR! peerinvalid Peer [email protected] wants bespoke@^1.0.0
npm ERR! peerinvalid Peer [email protected] wants bespoke@^1.0.0

npm ERR! System Darwin 13.3.0
npm ERR! command "node" "/usr/local/bin/npm" "i" "-D" "bespoke-jumpy"
npm ERR! cwd /Users/someuser/somerepo
npm ERR! node -v v0.10.31
npm ERR! npm -v 1.4.24
npm ERR! code EPEERINVALID

Might be related to the new plugin architecture, but I haven't dug that far.