Conversation
I'm all for this ... but @theefer, @robinedman and @cutandpastey might have some comments about it. |
Are you going to update all plugins to use helpers from scribe instead of scribe common? If planned for a later step, it might be worth doing at least one to prove it's doable (incl. running the plugin tests, bundling it correctly, loading it in, etc)? As per @OliverJAsh's comments in #268, do you have any solution in mind to enforce version matching between plugin and Scribe? (npm's I don't have any problem with this change as long as the problems people identified are considered. |
@theefer I wasn't clear whether I needed to release Scribe first then check the plugins or whether it would be enough to override the bower_module locally and then see what happens. As for version matching, I can't honestly say that I followed the meaning of the discussion. The thing that makes the most sense to my mind is to expose scribe.Node and scribe.Element on the scribe instance that you pass in to the plugin. Loading a separate object from a separate package doesn't make sense to me. |
You may (?) be able to test things without releasing them using
I think the gist of it is that because these helpers will evolve (new ones, fixed ones, deprecated ones (?)), you will likely want to enforce some versioning: This is currently done by:
As I wrote this, I wonder if the solution isn't simply to stop doing 2 and stop building Instead, declare the dependency on whatever version of This should solve the problem of having to re-build all plugins whenever Note that I think this is very similar to what you're suggesting doing by putting the helpers into It sounds almost too easy to be true, so there may be caveats? Can anyone tell me why my idea is dumb and doesn't work please? :-) Alternatively, if you still want to put the helpers back into But it's all fiddly enough that I would personally trial any change on a small scale before committing to it. |
I can't see anything wrong with your potential solution @theefer. I'm slightly lost on all the versioning stuff myself. The only problem I can see is that we will have to rebuild all of the plugins anyway to get rid of whatever version of scribe common they have in them. |
That's true regardless of the solution ( |
We need to talk IRL about this but I think having a separate library for your interfaces because you potentially want to make backwards incompatible changes is a sledgehammer to break a nut here. Using semantic versioning conventions on Scribe itself should be enough. |
I agree that we shouldn't make backwards incompatible changes, unless using semver to denote it. I think we haven't done that so far, so that's cool. We likely do want to maintain the ability to version for forward changes (you need at least version X of It seems that the suggestion of not bundling the helpers with the plugins should hopefully solve most problems, and it works regardless of whether they live in |
I am going to implement the suggestion of expose Node and Element on Scribe, which would then allow me to rewrite the "bundled" plugins to use this instead of the source directly. This should be sufficient proof of concept to show how plugins might be ported. |
So I like this solution. Keeping it simple. 👍 from me. For a change like this though, might be good to have another +1 too so we're all on the same page. @hmgibson23 ? |
It did fail the build though. |
@hmgibson23 The power of Travis rescheduled build compels you! |
👍 in that case |
Addresses #268 in the simplest way possible