You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the same configs are used for the build (deploy) and watch (development) tasks. The reasoning behind this is to avoid unexpected bugs that emerge from discrepancies between development and production code.
However, there are quite a few Babel and Webpack optimizations that make sense to use in production only, as they may hide important debugging information and slow down the build process.
I'm conflicted now. Perhaps it is worth exposing two config sets and let users decide whether they want to provide the same options to the build and watch tasks or not.
The build and watch core logic will be moved to another package, that is, each of these will be an independent function that takes a set of options. The generator will make use of this package, by default it will pass the same options to both functions but it will be easily customizable by the user.
This will be done after the v3 release, otherwise we will never reach the mythical 3.0.0 milestone.
Currently, the same configs are used for the build (deploy) and watch (development) tasks. The reasoning behind this is to avoid unexpected bugs that emerge from discrepancies between development and production code.
However, there are quite a few Babel and Webpack optimizations that make sense to use in production only, as they may hide important debugging information and slow down the build process.
I'm conflicted now. Perhaps it is worth exposing two config sets and let users decide whether they want to provide the same options to the build and watch tasks or not.
/cc @jaydson
The text was updated successfully, but these errors were encountered: