split into multiple projects/packages?

[millermedeiros]

split into multiple projects/packages?

[Raynos]

@millermedeiros the package manager issue is already solved. It's called use npm.

[millermedeiros]

advantages of a single project/package:

• discoverability (easier to find methods and browse docs since everything is at same place).
• less time spent on package.json
• avoid cluttering the npmjs repository.
• client-side package management is still in flux and having a single download makes everything simpler (even ad-hoc package management scripts - see gist)
• option to load whole lib/package in case user wants to (require('amd-utils/array') for brevity).
• easier to maintain:
  • no need for git submodules (which are a huge mess)
  • no need for separate repositories.
  • if change affects multiple packages we can bump just a single version (no need to update in multiple projects and do multiple npm publish).

disadvantages:

• some people don't like it.
• download a lot of files that might not be used (for me that is not a big deal, what matters is the code that goes into production).
• granular version numbers sometimes makes more sense (v1.0 to v1.2 might have changes that only affected modules you don't care).
• I don't get to be one of the most prolific authors on npm 😜

[millermedeiros]

some people even suggested that each method should be a separate package... of course it could be automated and I could flood npm with almost 200 modules at once. For now I don't think that is a smart idea, should not help anyone just make things harder... consuming modules will be harder since you need to list it twice (once on package.json and once on any module that requires it).

amd-utils does one thing and does it well. It provides generic utility methods, allowing you to load only what you use/need. It follows the same conventions through the whole package, this level of consistency is hard to match with modules provided by different maintainers. The main reason why code reuse is so difficult is because most systems work well separately but follow conflicting paradigms.

feedback is always welcome.

[conradz]

I'm currently not decided which way would be the best, but I would definitely be -1 on splitting each method into a separate package. You should be able to require a specific method, but having to list 50 methods in a package.json file that uses it is not maintainable. I wouldn't be opposed to splitting out each top-level folder (e.g. object, array, etc.) into a separate package, but I don't see any big benefit.

[unscriptable]

What matters to me most is that the modules aren't interdependent (at least not a lot of dependencies) and that I can access the functions directly. Don't make me require('amd-utils/something-big') just to get a single function.

I haven't given up on AMD package management, yet. :)

[millermedeiros]

@conradz for now I still agree with you, as a user and maintainer of this project having everything bundled into the same project was never an issue (besides of comments about it being "bloated"). I just place everything into a "lib/amd-utils" folder inside my project and don't need to worry about which methods depends on what. For me what matters is what goes into production.

@unscriptable there are cross-dependencies between packages, so handling it manually for an AMD user will be trickier as long as the package manager problem isn't solved.

on the AMD-user-land the verbosity can be solved with the packages or map configs (I know you are aware of it, maybe I should document it):

requirejs.config({
    map : {
       "*" : {
           "arr" : "lib/amd-utils/array",
           "obj" : "lib/amd-utils/object"
       }
    }
});

// now you can require the modules like
define(function(require, exports){
   var map = require('arr/map');
   var keys = require('obj/keys');
   ...
});

Unfortunately it seems that this feature will never be supported on node.js (see isaacs/npm#2944)

Everything would be easier if node.js/npm was more flexible... I really don't want to maintain a separate repository for node.js and AMD since pull requests and changes will be harder to track. I'm also trying to avoid an UMD wrapper around each module, AMD already adds enough boilerplate...

I would still like to see a good explanation about why some people prefer to install single function dependencies.

[Raynos]

@millermedeiros my opinion is use npm + browserify.

I mean yes splitting them out into multiple packages and modules is a good idea if you have a decent package manager.

[millermedeiros]

Having a single project haven't proven itself to be a real issue so far and maintaining the project the way it is right now is kinda easier anyway (cross dependencies, generators, test runner, build script, publishing).

I will try to limit the scope of this project to avoid becoming a huge kitchen sink, will try to keep it only for generic methods that could be part of a standard library (like Python, PHP, Ruby standard libraries). I already deprecated the financial package since I think it is outside the scope of this project (see #115).

Will close this issue until the front-end community sort out the package manager issue. Thanks for all the feedback.