I'm considering breaking Javascript Tools into separate projects. The current approach of having them all together introduces several problems, principally:

* Harder to get other devs to sign on to maintain (big package, daunting)
* Difficult and therefore slow to post new releases, hard to ensure that all components are ready for a new release at a given time

Anyone object to this potential change? Other thoughts?

Comments

nedjo’s picture

nedjo
he/him/his
Primary language English
commented

Another thing that's happening is that other projects are popping up that overlap or duplicate jstools functionality. This may be due in part to the lack of profile of the various modules included here.

Compared to when jstools was first posted, it's now much easier to manage installing and updating multiple dependent modules (update module, module dependency checking).

dman’s picture

dman commented

I think you're right.
For visibility of these atomic features, they'd be good on their own.
For issue tracking, the current system is awkward.

What do you propose would be left in the core jstools library? Would it be possible to think of the children as working stand-alone? I know I truly avoid layering in js libraries when I just want one little bit of functionality. This is important to consider, as many potential users are looking for one feature, and would balk at installing three or more modules to get something that can allegedly be done in one page of copy & paste from a script library.

The problem I've seen with branched sub-projects is mostly the difficulty of pushing any required changes back into the parent project when a child project requires it. But that doesn't need to be so hard.