Improving the JS Asset build pipeline

[bcardarella]

I've already spoken with @chrismccord and got the 👍 on this. I'm opening this issue to track progress, indicate what I intend to do, how I intend to implement, and solicit feedback.

What is being addressed

Right now the Webpack build pipeline pulls phoenix.js, phoenix_html.js, and phoenix_live_view.js from their respective Elixir package's deps/<name>/priv/static directories. See this screenshot from the compiled app.js file in a Phoenix 1.5.7 app:

I've collapsed the code so the source paths are all visible. These files in priv/static are pre-compiled, minified, and obfuscated. Diagnosing app issues or just trying to gain a greater understanding of the JS side of things within an app is incredibly difficult. Adding developer ergonomics like sourcemaps don't make it down to the pre-compiled files. There have been changes to add sourcemaps to the build pipelines that produce these files but that is not the best solution. Instead the current Phoenix environment (dev, prod, test) should dictate how these dependencies are built rather than being pre-built.

In addition, phoenix and phoenix_live_view are published to NPM. However they are included as file reference dependencies in package.json:

This is fine as it eliminates the need to re-download from NPM. However, each package is set up with the priv/static files at as main in their package.json:

So when import { Socket } from "phoenix" is called it is matching on the pre-compiled version only. And because the file reference in package.json just sets up a symlink:

this is why the compiled app.js file references ..deps/<name>/priv/static/<file>.js

There are two possible solutions:

1. Eliminate the pre-compiled JS files from the dependency packages. I know that part of the reasoning for them is so others that are not using Webpack can consume them. However, I would be interested to know if this is really a concern.
2. Change main to assets/js in each package

For the sake of causing the least amount of side-effects I'll move forward with the 2nd option for now. I'd like to get feedback on the reality of the 1st though.

[bcardarella]

With regards to the existing implementation of SourceMaps... does anyone have this working? According to terser-webpack-plugins own documentation, the currently used setting of eval-cheap-module-source-map is not supported: https://www.npmjs.com/package/terser-webpack-plugin/v/2.3.2#sourcemap

Works only with source-map, inline-source-map, hidden-source-map and nosources-source-map values for the devtool option.