Home Core Concepts Getting Started Customization Project Layout Presets Runners Scripts Sparky faq Contributing Fluent API Presets Runners (core)Runners (other)Starter Kits

# FAQ

### Why not a boilerplate or alternative?

Boilerplates are great resources for scaffolding out application-specific code which would be difficult or tedious to generate for every project. Unfortunately many projects also bake in build configuration into this process, causing a lot of duplication. If you need to make a change to your build steps, you are forced to make that change across all your similar projects. Using a preset rather than a boilerplate keeps this process DRY.

Tools like Create React App have been fantastic improvements to the tooling ecosystem, but unfortunately only work on specific environments like React, and do not allow simple extensibility of the build configuration. To answer this, new and similar projects are cropping up to build different types of projects, often duplicating efforts which miss out on the best practices to share with the other project types.

BeRun provides both boilerplates (starter kit templates) and separately allows their build configuration to be uniquely customized.

### Why don't presets use a normal webpack configuration object instead of the fluent API?

The webpack configuration works well when it is embedded into a single project, and it is the only configuration file to maintain. Once the configuration is no longer co-located with the project, and needs to be extended or modified across different projects, it becomes very messy to make those modifications.

For example, let's say that a preset instead used the webpack object configuration and added an instance of the `EnvironmentPlugin`:

    berun.webpack.plugins.push(new webpack.EnvironmentPlugin(['NODE_ENV']));

If you wanted to extend this plugin in your own project to add more environment variables, you would most likely resort to either adding a new instance of the `EnvironmentPlugin` by requiring webpack yourself, or looping through webpack's plugin array, removing the plugin, and re-instantiating it with your own arguments.

    berun.webpack.plugins = config.plugins.map(plugin => {
      if (plugin.constructor.name !== 'EnvironmentPlugin') {
        return plugin;
      }

      return new webpack.EnvironmentPlugin([...plugin.keys, ...customEnvironmentVariables]);
    });

This forces a much higher maintenance burden on your project, and this is only a very simple example. Modifying loaders created from raw webpack configuration objects can be much more unwieldy.

Using berun affords BeRun the ability to identify and manipulate parts of the configuration without resorting to object and array manipulation hacks, something not currently possible when working with raw webpack configuration data.

### Can I just re-use my existing webpack configuration?

The BeRun configuration does let you merge a configuration object, but does not accept a normal webpack configuration out of the box. Since BeRun uses BeRun Fluentand enforces naming of plugins, rules, and loaders, you must use an object that corresponds with this "schema". Typically this would involve transforming your webpack configuration to nest entities requiring a name into an object which maps the name to the entity.

In short, you must transform your webpack configuration in order to merge it into the BeRun configuration cleanly.

### What is the difference between runners and presets?

None, presets are runners, the difference is in name only. We typically want to use the term 'presets' when referring to major project types: React projects, Node.js projects, composite runners (conglomeration of many runners), etc.

The takeaway: most runners can just be runners, and use the term preset for major project types or composite runners.
‹ previous
next ›