Browser build location consistency

[alexjeffburke]

While implementing browser builds of many of the the modules I've noticed a couple of inconsistencies that I think are making setting this stuff up a little more tricky that it need be.

This issue is about the a difference within this plugin whose browser build is nested within the lib folder.

I propose copying the file in lib to the root of the package as a preversion step. If we do this, the script src of this plugin would be entirely consistent with the rest of the ecosystem. By using a copy operation we'd also maintain full backwards compatibility with existing test suites.

[sunesimonsen]

Could you elaborate on the stuff that makes the process more difficult.

[alexjeffburke]

@sunesimonsen this issue is about script src attribute - almost all the Unexpected plugins have their browser build in the root of the package except sinon, which means a one off path is required when it is used in the browser.

Other inconsistencies include the name used to register the plugin on the window - I'll enumerate that stuff separately.

[papandreou]

Since there is no build process in u-sinon I think it'd be annoying to version control an extra file, or even just publish an extra copy of it, for this purpose. It seems like an odd thing to standardize since the file name will vary as well, some will have a .min infix etc.

[papandreou]

Maybe we could use the browser field to point to the right location?

[alexjeffburke]

Hmm, I take the point but will push back a little - those small differences make setting up browser tests just a little more involved than they need be, and I'd just note that in most of the other plugins we do the build in postversion and we don't think about it. If we ever modernise -sinon and transpile maybe putting the build in the root is also an option :) As for the browser field, I think that's more when bundling - and we typically don't nudge people to do that with plugins when testing. But maybe we should consider setting it anyway

[papandreou]

Yeah, I think we should specify browser no matter what, I don't think there'd be any downside to that.

Isn't it pretty much the same, though? If these browser tests need the babelified version of the plugin, wouldn't it be fine (in general) to use the file deemed browser-ready? I don't think it matters if a bundler is involved?

I don't really know much about browser beyond what it says in that mini spec, but it looks like a good fit to me.

[alexjeffburke]

Ah that's a fair point - if you're bundling the tests and you're putting the plugins inside the bundle. Hmm - the reason the location hit me is my approach is build a bundle but ensure globals are referenced as externals. That means in my webpack/rollup config I declare something like:
'unexpected-http' => 'window.unexpectedHttp' and that's why I have to manually add the script tags. IIRC even in karma the scripts to inject array is filesystem paths rather than packages.