Rules_nodejs: webpack_bundle rule

Created on 12 May 2018  路  12Comments  路  Source: bazelbuild/rules_nodejs

Very similar to the rollup_bundle rule we have already.

I think the biggest benefit of this rule is to help explain what Bazel is about at a high level. People assume the ecosystem is an either-or, each-tool-is-a-build-tool because that has been so typical. By making our primary examples use Webpack, this just looks closer to the shape people expect, and less foreign. As @hansl has said, our users have an expectation that the toolchain uses Webpack, maybe because it's winning the popularity contest.

So we just want to say "hey Bazel is a wrapper for Webpack that moves where the loaders and plugins are implemented out to separate processes, but it has feature parity with what you have today for which bundles are produced, etc.

Rough design ideas:

  • What CLI to use? webpack-cli is a heavy dependency and has a lot of features we don't want. webpack-command is closer but very new, and also has things we don't want (like update-notifier) Maybe since all we need is webpack --config conf.file --quiet we only need tens of lines of code to write our own CLI around the webpack package?
  • Like rollup_bundle, we need to teach webpack how to resolve named modules via the module_name attribute on dependencies, and how to resolve in multiple root dirs
  • To roll this out, we should make another example in the Angular repo showing the 2.4kb Ivy hello world, and maybe also a code-split lazy-loaded Ivy example.
  • If we make Ivy do Bazel+Webpack, it will be a better example of how to change the Angular CLI to use Bazel.

See WIP in the webpack branch on my fork.

enhancement help wanted

Most helpful comment

@clydin is going to take a look at prototyping this in the next couple weeks.

We actually want to go a step further and use the DLLPlugin, so that we run webpack against individual libraries to produce some static metadata, which is then used at the root of the graph in the webpack_bundle rule to make it parallel and incremental.

All 12 comments

Hello @alexeagle, I'd really love to have this feature implemented, and I'd be glad to help you in building it. What can I do to help you with this?

@clydin is going to take a look at prototyping this in the next couple weeks.

We actually want to go a step further and use the DLLPlugin, so that we run webpack against individual libraries to produce some static metadata, which is then used at the root of the graph in the webpack_bundle rule to make it parallel and incremental.

@alexeagle @clydin and progress on the webpack_bundle prototype? The DLLPlugin sounds very promising and we are starting to get interested in a 'native' webpack rule.

No progress yet, we are forming our plans for Q4 and this might be on the list. Alternately, we might decide that systemJS 2.0 with native module loading is more modern and push on that first.
I think the big differentiator is whether webpack could give us dev-mode code splitting that scales (stays under 2s roundtrip for an app with 10k files)

SystemJS 2.0 does look interesting, so would the idea there to have bazel just do the typescript compilation but no bundling and just let systemjs handle the module resolution at runtime in the browser?

Or would the idea be more to still bundle, but with codesplitting in-place so only one of many bundles will have to rebuilt on code-change and then possibly have s.js just allow the loading of these in the browser?

The second one - except we shouldn't even need s.js if we use native modules, except on older browsers.

In the React-world we use a lot of different plug-ins for babel and webpack. For example, https://www.styled-components.com/docs/tooling for styled-components. For large applications, it seems reasonable to build each module with Webpack as separate UMD-library and use SystemJS as module loader. This code-splitting should work in development mode and support incremental builds.

What's the status on this effort - any progress?

I implemented a v0 webpack_bundle rule - noted the missing pieces in the README there:
https://github.com/alexeagle/rules_nodejs/tree/webpack/packages/webpack

I implemented a v0 webpack_bundle rule - noted the missing pieces in the README there:
https://github.com/alexeagle/rules_nodejs/tree/webpack/packages/webpack

Doesn't look like v0 implementation survived or the branch was deleted/moved.
What's the status of the effort as of today?

I implemented a v0 webpack_bundle rule - noted the missing pieces in the README there:
https://github.com/alexeagle/rules_nodejs/tree/webpack/packages/webpack

Doesn't look like v0 implementation survived or the branch was deleted/moved.
What's the status of the effort as of today?

It looks like it was moved to https://github.com/alexeagle/rules_nodejs/tree/webpack/packages/labs/webpack.

yes thanks @clintharrison - this is an early minimal version, we probably need to support you bringing your own webpack plugins and config file. but I'll close this for now.
Example usage is https://github.com/bazelbuild/rules_nodejs/tree/master/e2e/webpack

Was this page helpful?
0 / 5 - 0 ratings