Feature request - expose Haul as a library

Thank you guys for your amazing work! The need for Webpack-friendly React Native packager is really strong since it is very flexible, number one bundler at the moment and the fact that React Native has its own incompatible packager raises many problems with code sharing between mobile frontend and web frontend or even backend of the same application.

I would like to open discussion about exposing Haul as a library with API for:

• Making React Native webpack config with Haul entry points, resolvers, loaders, babel addons
• Using Haul as a webpack middleware, in similar fashion as webpack-dev-middleware will enable developers to deeply integrate Haul with their Webpack projects in a programmatic way. Much like the Webpack itself can be attached in a programmatic way to project via webpack-dev-middleware and instantiating Webpack compiler instances directly from Node.js code, without the need for launching command line Node.js process.

This is needed for projects that already use Webpack in a programmatic way via its Javascript API and want to include Haul as well the same way.

[thymikee]

As a maintainer of @react-native-community/cli I fully support @zamotany’s idea to utilize Haul (and Webpack) as a CLI plugin.

We were already thinking about refactoring the way we use bundlers, as it’s pretty tightly scoped to Metro at the moment. By creating a unified interface for bundler interactions, any bundler, like Metro or Haul/Webpack, could create a suitable adapter. Some reference: https://github.com/react-native-community/cli/issues/46.

[zamotany]

@hedgepigdaniel Thanks for this detailed comment and while I do agree and would like to see Haul being just a set of utilities for Webpack (loaders, plugins, polyfills, etc) and a plugin for @react-native-community/cli that would use you configs files (eg webpack.config.js and others) to run Haul instead of Metro, there are some problems with that approach that we’ve already experienced.

Most noticeably lack of understanding or knowledge about Webpack. In the beginning Haul required you to have webpack.config.js and provided a CLI that would use utilise this config. This led to many issues, about not Haul, but Webpack - how to transpilenode_modules for example. At some point it was maintenance nightmare to solve other peoples problems with Webpack (not Haul) that we made a decision to hide Webpack config for regular users.

If we switch to providing utilities to configure Webpack yourself, that would be awesome for advanced users like yourself, but we would be opening ourselves to a rabbit hole of mistargeted questions about Webpack, and saying that This is Webpack issue, not Haul. Please raise this issue on Webpack issue tracker or Stackoverflow is not a good DX.

Next problem is limited resource and bandwidth so make that happen. Currently I’m the only person maintaining Haul with limited time to do so. I would be happy to help and provide guidance for any external contributor to implement those features or refactor some code in a way that would allow those Webpack utilities to be used separately from Haul CLI.

I don’t think currently we will be able to straightaway go with the changes/API you’ve proposed, we could refactor pieces that are related to webpack, to allows for this low-level customisations. We cannot just drop the Haul CLI, because of companies that already invested in Haul and provided sponsoring for few features. The path forward for Haul is to either have community that contributes with PRs or companies that are willing to sponsor the work in Haul.

---

Now in the ideal world, Haul would consist of only Webpack utilities and a small bundler API that would be used by @react-native-community/cli, so the bundle command and packager server will be handled by @react-native-community/cli and only the bundling itself will be a handled by Haul, by as I said without help of the community or companies I’m not sure if we get there.

cc: @thymikee @grabbou