Remove the Dependency on Babel: Allow Prebid to be used with any build system

[cameron-brown-future]

Type of issue

Feature request

Description

The SWC loader is much faster than the babel loader, it would be ideal if the prebid node module could add support to be compiled with this loader if desired.

Speculation:
The babel loader is currently required to replace certain compilation variables or perform other complex logic, and requires a special babel config. It is unknown if SWC supports the abilities required to replace this, but if it does it should be used for performance reasons.

SWC also may increase the package size, but has minification options that may even reduce the package size if used properly, this would need to be taken into account before committing to supporting SWC

Steps to reproduce

• Install the SWC loader in an existing project that uses prebid.js
npm i --save-dev @swc/core swc-loader
• Replace babel-loader with swc-loader in the webpack config
• Attempt to run the code as normal

Expected results

The code compiles and runs as normal if SWC is used, perhaps with some additional config.

Actual results

When using the swc-loader instead of the babel-loader a reference error for $$DEFINE_PREBID_GLOBAL$$ occurs when running the compiled code.

[dgirardi]

Related to #9723 and #5287. Rather than trying to support the newest tool, I'd prefer to avoid the need for a precompilation step and publish a version that can be imported directly.

[patmmccann]

@cameron-brown-future we'd welcome your contribution to get this working, thanks!

[ilyaryabchinski]

Hey @dgirardi! First of all, thanks for your contributions to this amazing repo 🙏 I think I might be having similar issues as I am using Next.js and SWC in my project.

I agree that the best solution to this issue would be to remove the need for the precompilation step and allow consumers to just directly import modules. I've noticed that there is already a solution #8175 for the issue, but the PR has not been merged yet.

Is there a workaround for now? And do you need any help to get it merged sooner? I think I can jump in if needed 🙏

Thank you 🙌

[dgirardi]

@ilyaryabchinski I am not happy with that PR for several reasons - but if it solves this problem for you I can try to get it in as a temporary workaround. It essentially makes what you get from the download page available through NPM.

I think the "real" solution is split the compilation in two steps:

1. pass source through our custom babel plugin only, which just replaces "macros" such as $$PREBID_GLOBAL$$ or FEATURES.NATIVE. This should keep the output as ES6 modules, without any browser shims / other babel presets. I think this is what makes sense for NPM consumers to import.
2. pass output of step 1 through the rest of our build system, with webpack generating discrete module chunks that make sense for our download page.

I am not sure how to deal with compile-time feature flags in step 1 (FEATURES.*). We could run the build for each possible combination and let the consumer choose what to import (maybe with some utilities to make that easier). Or we could run a "standard" build with all features enabled, and one where the flags are left untranslated in the source, letting the consumer set them up in their build system. I'm open to suggestions on this one - how do projects deal with compile time flags and NPM?

[ilyaryabchinski]

For npm consumers the ideal way IMO would be to avoid Babel/swc/new_fancy_js_transpiler precompilation step on the consumer project build system side and make all the features/modules to be pluggable.

In this case I can avoid changing my build system and the Prebid usage would be as simple as: importing the core module and then importing the modules that I need for my header bidding configuration.

Not sure if it's feasible since I'm obviously not familiar with the project constraints but seems like it may affect building discrete chunks for the download page 🤔

[cameron-brown-future]

We've just encountered the same issue while trying out rspack (A rust-based replacement for webpack)

This supports the idea posed by @dgirardi and @ilyaryabchinski that a more generic solution that removes the need for any pre-compiation would be better than just supporting the shiniest new compiler.