Skip to content
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

Modularization #31

Open
JaKXz opened this issue Jun 9, 2015 · 1 comment
Open

Modularization #31

JaKXz opened this issue Jun 9, 2015 · 1 comment

Comments

@JaKXz
Copy link

JaKXz commented Jun 9, 2015

This is a great package, and thank you so much for it! However, I think it could be improved if each algorithm was it's own file, for those of us who only need one or two different algorithms.

Then, the build process could concatenate all the files and your bower.json could remain the same, but overrides could be specified as necessary, e.g.

"overrides": {
  "jshashes": {
    "main": "sha256.js"
  }
}

What do you think?

@h2non
Copy link
Owner

h2non commented Jun 10, 2015

I tend to agree. This was clearly a smell when the library borns. Isolation is generally a good approach, It's more maintainable, more readable and hygienic.

From the other hand, taking into account the nature of node's modules, loading a bunch of them is not a problem, neither in the performance side or bad practice. IMO the final benefit of doing this is not too much considerable.

To be honest, I don't have in mind releasing a fresh version which splits the algorithms, but maybe I'll be able to it in a future, however I'm always open to accept a PR, specially for this kind of features.

The hard part here is about coupling, since some functions are reused between multiple algorithms internal logic, so you should be careful.

For browser packaging, my proposal would be definitively using browserify.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants