prebid
Build system: make compiled prebid-core and modules available for npm consumers
Type of change
- [x] Feature
- [x] Build related changes
Description of change
This updates the build to make compiled files (both minified and not) available under 'dist', so that NPM consumers may use them without needing to set up Babel transpilation.
Resolves https://github.com/prebid/Prebid.js/issues/5287
NOTE: this also needs an update in the release process; please review but do not merge.
There's quite a bit of interest about this expressed in #5287, although that issue is quite old now and I'm not sure if that still applies.
@khatibda does this approach match your expectation for a "consumer" npm package? The usage would look like:
import 'prebid.js/dist/min/prebid-core.js';
import 'prebid.js/dist/min/some-module.js';
// ...
pbjs.processQueue();
with no transpilation necessary. There is no automagical detection of production / development flags as I'm not sure how you could do that without being opinionated about the build tools in use - which is what I think React does.
@khatibda does this approach match your expectation for a "consumer" npm package? The usage would look like:
no transpiling would be magical!
i'm assuming consumer npm use case is mostly a "production" case even in dev. different from contributor npm use case. but i could be wrong. regardless, at least for webpack, if both dev/prod import paths are available, there are ways to handle.
most major package imports look a little "nicer" in terms of syntax used, e.g. import 'prebid/core', but i think that's probably just sugar and not a big deal if complicated to solve.
@khatibda we're having some trouble here in that we cannot find a second reviewer. Are you able to review?
@dgirardi
final q, i recall the big hangup before was about dynamically defining the global variable name that happened at transpile time
i don't see any commentary on this thread, but i do see the inline comment example referring to "pbjs.processQueue()"
so...does this presume/mandate that the origin global is pbjs? or do i have it wrong?
(which i suppose devs can reference themselves via variable reference if they really need to.)
@khatibda yes - the global var is always pbjs unless you run the build yourself.
I suppose we could try to transpile into es6 modules and avoid the global completely.
@khatibda yes - the global var is always
pbjsunless you run the build yourself.I suppose we could try to transpile into es6 modules and avoid the global completely.
i think pbjs is great/fine. it will work better than no globals. going to approve.
@dgirardi this appears ready to merge with a docs commit; some changes to https://github.com/dgirardi/Prebid.js/blob/consumer-npm/README.md, and the conflict resolved.
@patmmccann it also needs a change in the release automation scripts (and some coordination to make them happen at the same time), so keep this labeled as do not merge please - I'll follow up shortly with conflict resolution /README updates (I don't think docs cover the build process, but correct me if that needs an update as well)
is it possible to rely on https://github.com/prebid/Prebid.js/blob/97ae929aee9c909587ca5fce2580c910db67c2cd/src/prebidGlobal.js#L9 to get the global?
@patmmccann yes, but I don't think it makes sense in this context - that will always contain just 'pbjs' unless you ran a custom build, in which case you probably already know what you set it to.
We are using custom builds as well, but we quite like the Babel step in between as it allows us to compile different bundles depending on the targeted browser ( es6 module build and es5 with polyfills ).
@khatibda getting rid of Babel in your build means you rely on prebid.js output being compatible with the devices you want your bundle to be compatible. This can come at a cost of larger JS bundles.
While I think this is interesting for faster example builds, this is not something we would use for production.
The docs changes @dgirardi proposes should also solve https://github.com/prebid/Prebid.js/issues/6661