Mithril.js: Make mithril code even smaller by "define plugin".

[mikejav]

What do you think about remove errors throwing for production? IMO it's good idea cause of if we have tested our app the errors most likely will not occur in production.

This can be done by Webpack's DefinePlugin (click link to read how exactly this works),
but also by babel-plugin-transform-define.

I think this is good idea for leave errors in development not minified version, and remove it in the minified production version.
I also think that this is good practise- other frameworks like Vue.js cuts error code from production build.

Example:

this part of code:

// Because sloppy mode sucks
var attrs = arguments[1], start = 2, children
if (selector == null || typeof selector !== "string" && typeof selector !== "function" && typeof selector.view !== "function") {
    throw Error("The selector must be either a string or a component.");
}
if (typeof selector === "string") {
    var cached = selectorCache[selector] || compileSelector(selector)
}

will be:

// Because sloppy mode sucks
var attrs = arguments[1], start = 2, children
if (BUILD_TARGET !== "production") {
    if (selector == null || typeof selector !== "string" && typeof selector !== "function" && typeof selector.view !== "function") {
        throw Error("The selector must be either a string or a component.");
    }
}
if (typeof selector === "string") {
    var cached = selectorCache[selector] || compileSelector(selector)
}

and the example part of babel config:

{
  "plugins": [
    ["transform-define", {
      "BUILD_TARGET": "production"
    }]
  ]
}

Then you could write additional code errors/warnings without worrying about the production bundle size.

[sebastiansandqvist]

I don't think this necessary for a few reasons:

1. You want to have consistent execution in all environments. When you say other frameworks leave out errors in production, those are typically the friendly console.warn and console.error types of errors meant to help with development that do not have any effect on how the app executes. I'm not sure about Vue, but with React I know that is the case. In general, you do not want to have something throw in development but not in production because through some hidden complexity (maybe a try/catch, maybe a promise that swallows an error, etc.) it could be possible that your application executes differently in those different environments.
2. There aren't enough places in which mithril throws an error that this would save any noticeable space, if file size is the concern.
3. Mithril isn't using webpack (I'd say that's a plus!) because it has its own simple bundler. It's not using babel because it doesn't need it--the codebase is all es5. Introducing either one just to strip out 10-20 lines of code introduces complexity and could be detrimental to some of the manual performance optimizations that have been done on the library.

[isiahmeadows]

BTW, we've specifically been skeptical of introducing Webpack and other build systems (the only one we really gave much thought into was Rollup, but it was too immature at the time). And our internal bundler provides Rollup-like size.

UglifyJS provides a --define option that does exactly this, though, and that IMHO would probably be the best solution to this issue. And I'm actually a minor 👍 to this, because conditional compilation would enable us to do internal asserts (avoiding a whole class of bugs) that would send performance down the drain if we don't disable them.

[donkeybonks]

I use this in production for a very large app and support this but please run the unit tests with the production flags set.