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:
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?module_name attribute on dependencies, and how to resolve in multiple root dirsSee WIP in the webpack branch on my fork.
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_bundlerule - 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_bundlerule - noted the missing pieces in the README there:
https://github.com/alexeagle/rules_nodejs/tree/webpack/packages/webpackDoesn'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
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_bundlerule to make it parallel and incremental.