Haul: EvalSourceMapDevToolPlugin can break some dev platforms

[rdy]

In some js environments it isn't safe or allowed to use EvalSourceMapDevToolPlugin. By default this appears to be injected in dev mode. Is there any reason not to look at the devtool property in the webpack config and choose eval if devtool isn't specified? Otherwise we could choose a different source map plugin based on the devtool settings. We could attempt to honor some of the settings, minimally giving the user the ability to choose between eval and source map would be helpful. I'd try to respect cheap as well but inline doesn't appear to work with haul.

I'm happy to send a PR demonstrating this, but I wanted to see what the feeling on respecting devtool was.

[zamotany]

The source map is a tricky problem here: we need eval-source-map for debugger and source-map for symbolicate middleware to get proper filenames and lines in red screen within the app.

[rdy]

I think I'd like to keep the existing behavior, but allow the eval-source-map to be disabled. In the general case I think EvalSourceMapDevToolPlugin is fine\, I'm working with a platform for eval isn't allowed so I need a hook to turn it off. Wasn't there a time where source-map was used also in __DEV__ mode. What does the debugger need exactly from the eval-source-map? The source-map and use of symbolicate makes sense to me.

If the need for the eval source maps is for stack traces I've had some success with https://www.npmjs.com/package/babel-plugin-source-map-support. It loads the source map synchronously in files, maybe it would be possible to use in place of eval for platforms that don't allow it.

I'd love to see a solution that works generally for most, which is probably what already exists with eval. But having some kind of plugin control would be welcome.

[zamotany]

Revamped version of Haul on next branch doesn't have that issue, since by default it uses SourceMapDevToolPlugin and EvalSourceMapDevToolPlugin is an opt-in.