Structure proposal

[johngeorgewright]

Type of issue

Feature

Description

I'd like to propose a new structure to the Prebid.js project which could reduce our build time, file size output and increase ease of development.

Currently to include Prebid.js in to our project, we need to:

1. fork it
2. add our own custom adapters to the fork.
3. create a build with only the adapters we're interested in
4. include the dev output in the top of our project so it can be minified without warnings/errors

The problem with this is we now have duplicated browserify code in our project, which significantly increases our output size, and we need to constantly maintain our fork and merge your changes in to it.

What I'd like to suggest is split this repo in to many repos. Have a core Prebid repo and one repo for each adapter... just like you would for something like Grunt, Gulp, Webpack etc.

A little example of a project that might use it:

/* package.json */
{
  "name": "my-adverts",
  "main": "index.js",
  "devDependencies": {
    "prebid.js": "^1.0.0",
    "prebid.js-adapter-appnexus": "^1.0.0",
    "prebid.js-adapter-openx": "^1.0.0"
  }
}

// index.js
import pbjs from 'prebid.js'
import appNexus from 'prebid.js-adapter-appnexus'
import openX from 'prebid.js-adapter-openX'

pbjs.use(appNexus)
pbjs.use(openX)
pbjs.addAdUnits([...])

This way we no longer need to maintain a fork, we only include the adapters we need to, and people can start building and maintaining adapters without needing to commit to the core repo.

If you really want to, you could also have a prebid.js-builder project to include all your webpack config incase people want to create standalone versions.

If this is something you'd entertain, I'd be quite happy to get involved.

[mkendall07]

hey @johngeorgewright

Yeah we've discussed this internally. In fact @snapwich is currently attempting to build something similar with modules

The gist is that each "module" would be able to be built separately from the prebid core and those files could be concated together at run time. We'd love any feedback you have on this approach!

[mkendall07]

related https://github.com/prebid/Prebid.js/issues/1086

[snapwich]

Hi @johngeorgewright, as Matt said, I am in the process of trying to solve part of this problem. Most of the adapters will remain inside this repository since we've decided to go with a mono-repo design to help simplify versioning issues and the peer review process for core modules. However, I am planning on making the module system able to pull in outside modules that are in the npm repo, so that might solve that part of your problem.

The crux of your issue seems to be including Prebid.js in your browserify build though. That definitely won't happen anytime soon as our build is currently dependent on a webpack build process due to loader usage and such. However, I am attempting to simplify the build process to be less reliant on custom loaders (such as the adapter loader) which may make a refactor like you're suggesting more feasible in the future.

[vgvbach95]

Hello @snapwich, having the ability to have custom npm maintained builds, similar to how projects such as lodash do so, would be incredibly useful. Including all the modules in a build is too heavyweight, especially on mobile websites. The current npm build is over 300kB, but a custom build is closer to 80kB, which makes a huge difference in client side load times. Maintaining a custom build is costly as well without a package manager in the middle.

This feature would be hugely beneficial, so if there is a way I can get involved to help, please let me know.

[mkendall07]

@vgvbach95 How does this work in practice? Given the number of options we have in the /modules directory - permutations of each of these as a custom build seems expensive. How would you suggest we handle it?

[mkendall07]

So the new build system almost achieves these goals I think. I'm going to close this as we don't have any current plans to split up the project into multiple projects.