This is bound to be controversial, but...
Javascript packages have been more and more moving towards small, core packages to reduce bloat in their dependent packages. Two examples of this are grunt, and babel, who have respectively split out functionality between ['grunt', 'grunt-cli', 'grunt-contrib-sass', 'gulp-contrib-whatever','etc']
and ['babel','babel-es2015','babel-jsx','etc']
. I believe we should at least consider this approach for meyda, purely because there are many different use cases for our users, and a growing one-size-fits-all package might not be the best way to serve users. This isn't a case like C/C++, where a library is included but only the linked-to code remains in the binary after compilation, when a package depends on Meyda it must (some caveats, but usually does) deploy with the entire package, including files that will never get used in the production deployment.
Use cases for meyda include:
- Frontend developers who want to run meyda in the browser
- Node users who want to run meyda in realtime or "surrealtime" ✨
- Users who want to use the CLI
- People who want to contribute to Meyda
Cleary those who wish to contribute to Meyda should use the git repository, but the other usecases are not so straightforward. Frontend developers can use both npm or bower to install packages, so it's not entirely clear which files should be in the npm package. It's pretty clear that the bower package shouldn't include the node distribution files (for those who may be unfamiliar, we compile into a minified concatenated file for the web, and to unminified unconcatenated files with module loading for node), but should the node package contain the distribution files? Should we include instructions in the documentation for web developers using the npm distribution to link to the web distribution file instead of the node one, or should we point out that if they include via npm and therefore get the node distribution from require they should take care that browserify (or whatever equivalent tool) is properly requiring the nested files for their build process? Probably neither of those need to be distributed the source ES6 code or the tests, or the config files for the CI services/linter/etc, or the CLI. Users who want to use the CLI probably don't need the source code, just the distribution code, but users who want to use the node module don't necessarily need the cli.
All of this is fine, if meyda is only used infrequently on a small scale, but if meyda is ever included on a project with a very high deploy frequency, the extra cost of deploying the extraneous files could really add up. Given our new focus on offline, I don't think that scenario is too far fetched. In my opinion, we should probably discuss the above in order to make sure meyda serves the widest variety of use cases in the best way possible.