webpack-build design decisions

[donasaur]

1. Is there a reason why the stats field of the data object only contains a subset of the original stats object provided by webpack? It would be nice if it contained all the fields of the original stats object so users have a better idea of what the wrapper exposes. This way, they don't have to learn too many new things beyond the original webpack.

2. Also, would it be possible to refactor the webpack-build API to take in a webpack config object in addition to (or in place of) a path to a webpack config file? The only apparent problem I see with doing this is that you need the config file path to compute the timestamp associated with the config file. However, why is it even necessary to keep track of the config timestamp?

[markfinger]

1. it's mostly for optimizations around caching and serializanion. From memory, it omits the source and modules which tend to contain multiple megabytes of data. I think there's a handleErrAndStats function that takes the subset, so it'd be trivial to add an option to return the complete stats object.

2. yeah, I think some parts of the lower level API still allow config objects, so it's possible, but it'd i suspect that it may break some of the higher level parts, like the persistent caching. The config timestamp is used for cache invalidation and to provide an indication if your build is out of sync with your config file (mostly useful when you git pull and forget to restart the process).

[markfinger]

Re 2: it shouldn't be too hard to add support for passing a config object in as well as a path. That'd ensure that the caching still works, and programmatic use would be easier.