Create development bundle with inline source maps

[lukaszsamson]

This PR is a PoC of a solution mentioned in https://github.com/phoenixframework/phoenix_live_dashboard/pull/158#issuecomment-644334630. While it works, it's not optimal for local development (mix dev) because it performs unnecessary optimizations and source map generation. We would require another env variable to differentiate local development from running live_dashboard as a dependancy in dev and passing --mode development in dev.exs.

Resolves #150

[josevalim]

Is this building only app.dev.js with “mix dev” or both files?

[lukaszsamson]

Only app.dev.js. It builds with the same settings as build.development from package.json scripts. Because the two builds have different env and mode thy need to be run as separate steps. That's why I added build script.

[josevalim]

I am worried we (the maintainers) will forget to run mix build before release. I would prefer if we always built both bundles, so we don't have to worry about extra steps. Would that be possible?

[lukaszsamson]

It can be done on the npm side with prebuild/prewatch scripts (and on the mix side with publish alias)

[josevalim]

Could we start two watchers on the mix dev side of things?

[lukaszsamson]

Could we start two watchers on the mix dev side of things?

If webpack build cache is race conditions free ;)

[josevalim]

I see, unfortunately I am worried about having two entry points/commands to run and having them getting out of sync. That would be a deal breaker for me. :/

Another option is for us to generate the source maps file separately and then, when sending the JS code to the client, we do a String.replace(js, "example.com", "current_url"). Could that work?

[archdragon]

Thanks for taking a look at this!

Just a quick question - why not just completely skip all optimization/minimizing when building the development bundle? Wouldn't that achieve the same effect?

[lukaszsamson]

Just a quick question - why not just completely skip all optimization/minimizing when building the development bundle? Wouldn't that achieve the same effect?

Not exactly. The source is transpiled by babel and when it's bundled by webpack it looses original module structure.

[lukaszsamson]

Could we start two watchers on the mix dev side of things?

If webpack build cache is race conditions free ;)

I tried that and it seems to work

[josevalim]

Ping!

[lukaszsamson]

@josevalim I got impression that there is no consensus on how and if to approach this. Besides even with the changes from that branch I'm not able do debug https://github.com/phoenixframework/phoenix_live_dashboard/issues/165 as live_view and phoenix js deps come already minified and obfuscated. The better solution would be to get them unminified from npm and use js build tools in the release process.

[maennchen]

@lukaszsamson Both Phoenix & Phoenix Live View are going to expose Source Maps starting from the next release.

• phoenix: https://github.com/phoenixframework/phoenix/pull/4276 (already merged)
• phoenix_live_view: https://github.com/phoenixframework/phoenix_live_view/pull/1502 (will be merged soon)

One small question about this PR: Why would you only add Source Maps to the dev bundle and not to the Prod one as well?

[lukaszsamson]

Both Phoenix & Phoenix Live View are going to expose Source Maps starting from the next release.

Great

One small question about this PR: Why would you only add Source Maps to the dev bundle and not to the Prod one as well?

@maennchen IIRC there were concerns about bundle size - inline source maps significantly increase download size and parsing time on index.html

[maennchen]

~~@lukaszsamson Do we need inline source maps? Normal sourcemaps with a reference comment in the js should work as well, no?~~

Edit: never mind, we're loading it inline...