idea: publish hoodie-client-built: only built files without dependencies

[gr2m]

Hoodie only needs the built version, it does not browserify hoodie-client on the fly. So how about we create another npm package which only has the built files and no dependencies or other code, to speed up the npm install for hoodie and reduce dependencies?

@boennemann what do you think?

[boennemann]

My first reaction to a separate package was rather negative, but after thinking about it I see how it could work. Generally I would want to avoid having a separate package if possible. If I understood you correctly you don't want a separate repo though, right, just publish two packages from this repo? (Huge -1 to a separate repo)

Option 1: redefine dependencies as dev + peerDependencies

Include built files and src files in package. Allow hoodie-server to serve bundle including all dependencies. If app wants to require('hoodie-client') it can install peerDependencies and then it works.

• Saves roundtrips if require('hoodie-client') isn't desired
• allows for effective deduplication
• logs warnings for missing peerDevs out of the box
• needs duplicate dependency definition

Option 2: two separate packages

Publish hoodie-client-precompiled and hoodie-client separately.

• Saves roundtrips if require('hoodie-client') isn't desired
• allows for effective deduplication
• either require('hoodie-client') doesn't work out of the box, or if it's installed by default the saved roundtrips gone again
• multiple packages for the same source seem wrong, screaming for inconsistencies and tooling overhead

Option 3: bundle dependencies

• saves roundtrips
• ensures exact dependency tree
• both /hoodie/bundle.js and require('hoodie-client') work out of the box
• not sure how it's compatible with our deduplication efforts, not saying it doesn't work, just needs some investigation, might need explicit npm dedupe
• slightly larger bundle size, roundtrips that take the most time still saved, mostly cached

---

As I said before I think it's really cool that hoodie serves a precompiled bundle, but for production we should encourage requiring the source files, to allow browserify/webpack to deduplicate dependencies, and e.g. use babel/babel-lodash to get rid of unused modules. I think we're easily in the multiple hundreds of saved kbs with this.

After thinking about this now I'm preferring # 3. It think it would be super cool to have /hoodie/bundle.js with the prebuilt file, and at the same time map the hoodie-client source files to the top-level hoodie's "browser" field. Then people can use the <script> tag for quick demos to get going and at the same time just require('hoodie') in their client code. This way the entry is still super easy, but we're not punishing people for using the encouraged way, with additional steps.

While doing this it would make sense to think about using the # 1 approach for all dependencies of hoodie-client, i.e. move all their current bigger dependencies to dev/peerDependencies and install e.g. a single lodash version in this repo. This way npm could warn us if the hoodie-client depends on multiple lodash versions.

Edit: top-level hoodie already bundles dependencies, so # 3 is pretty much already in effect, just on a different level.