Build minified and unminified bundles

[pimterry]

I've defaulted to the minified version (by setting that as .browser in package.json), which I think is probably preferable, but up for debate.

[emirotin]

Debatable indeed because the browser field is always used by the bundler like browserify/webpack.
I've also suddenly realized that we'd want to use the source version in our own code (to dedupe the bluebird/lodash/etc) which will contradict with the browser field (as it will provide the UMD bundle instead).
What do you think?

[pimterry]

Mmm, this is interesting. I haven't really been thinking about downstream bundling concerns, because if you're bundling downstream generally you don't want us to provide a browser bundle.

As you mention for in the UI case, for example, we really want to just depend on the raw source so that everything gets deduped and you can control bundling yourself, and I think that probably holds for nearly 100% of other bundling users too. I can't think of any reason you'd normally want the bundle in these cases.

Given that, the use case for the bundle is in non-commonjs bundled environments - raw globals, requirejs, maybe more exotic things. I don't think any of other options use the browser field, so we should actually just drop it entirely, and have everything that uses package.json get the non-bundled version, and people use the bundled version only when they're setting things up manually. Does that sound reasonable?

[emirotin]

Yes I think that's the proper way to go.

…

On Tue, Jan 10, 2017 at 7:18 PM, Tim Perry ***@***.***> wrote: Mmm, this is interesting. I haven't really been thinking about downstream bundling concerns, because if you're bundling downstream generally you don't want us to provide a browser bundle. As you mention for in the UI case, for example, we really want to just depend on the raw source so that everything gets deduped and you can control bundling yourself, and I think that probably holds for nearly 100% of other bundling users too. I can't think of any reason you'd normally want the bundle in these cases. Given that, the use case for the bundle is in non-commonjs bundled environments - raw globals, requirejs, maybe more exotic things. I don't think any of other options use the browser field, so we should actually just drop it entirely, and have everything that uses package.json get the non-bundled version, and people use the bundled version only when they're setting things up manually. Does that sound reasonable? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#253 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAgGCC6d7dUr8DArJDjKleh1OQ_DPgMEks5rQ69zgaJpZM4LfhQ4> .

-- Eugene Mirotin Senior Frontend Engineer site: Resin.io <https://resin.io/>, twitter: @resin_io <https://twitter.com/resin_io>

[houndci-bot]

Unnecessary double quotes are forbidden.

[pimterry]

Ah, wait. There's still the other module-exclusion bundling problem. The config in this module currently lets us exclude some of its deps, which keeps downstream bundles smaller, and we don't share any of that info if we don't use the bundle when bundling downstream. Interesting...

This is where the browser field is supposed to come in: if we point it at source that never even require()s the modules we want to exclude (i.e. statically never even considers requiring them, rather than just hiding it behind an IS_BROWSER test) then browserify won't ever try to include them at all, even downstream. In principle that's doable with some refactoring, but it's a fairly wide ranging change. We'd need to build browser/non-browser versions of the relevant bits of this module and the other used resin modules, so that as browserify walks the tree it never sees rindle, for example.

For now though, as above, I think we still want to drop the browser field. Note that this means we're expecting downstream consumers to manually exclude modules though (but that's ok since the main downstream consumer right away will be us). We can pick up a separate task later to provide browserify/webpack-friendly builds with automagically exclude the right dependencies, since that's a larger job and it should be easily backward compatible anyway.

I've now pushed a browser-less update. Let me know if you're happy with all this and I'll merge and file an issue to look at the rest later.

[emirotin]

We can pick up a separate task later to provide

browserify/webpack-friendly builds with automagically exclude the right dependencies, since that's a larger job and it should be easily backward compatible anyway. Yeah I've mentioned that as a nice to have thing though I don't know yet how to implement it properly. Anyway right now the only browser consumer is us indeed so in the works case other users would just get suboptimal bundle size. LGTM to merge. Could you also add a small section to the readme listing the modules that can be safely dropped when bundling for the browser?

…

-- Eugene Mirotin Senior Frontend Engineer site: Resin.io <https://resin.io/>, twitter: @resin_io <https://twitter.com/resin_io>

[pimterry]

Readme note added, merging.