-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
split into multiple projects/packages? #113
Comments
advantages of a single project/package:
disadvantages:
|
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 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. |
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 |
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 I haven't given up on AMD package management, yet. :) |
@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 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. |
@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. |
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. |
@millermedeiros the package manager issue is already solved. It's called use npm. |
It seems that some people don't like the fact that amd-utils is a single package, they think it goes against the node.js philosophy of smaller being better (see: 1 and 2).
The text was updated successfully, but these errors were encountered: