Development vs Production

Uglify/Minify

The web is a place where size matters. If you were to look at the size of a typical node_modules directory, you might notice that it is very large. Here is the size of the modules directory for the courseware example site:

$ du -sh node_modules
586M	node_modules

No client ever wants to download half a gigabyte to show a web page! So what actually gets sent to the user? Obviously enough, only what they need. The node_modules directory contains development tools and code meant only for the act of building libraries that users do not need. There’s another part of the story though.

In addition to only sending what is necessary, production code should be minified. One very common tool to accomplish this task is Uglify JS. Uglify takes input javascript and outputs mangled-but-equivalent javascript that contains as few characters as possible. Things like line breaks, long variable names, other whitespace, and more are not necessary in production code.

Given some input JS:

input.js
let x = 3;

function square(x) {
	return x * x;
}

console.log(square(x));

I now run:

npm install uglify-js
npx uglifyjs --compress --mangle -- input.js > output.js

Here is some output:

output.js
let x=3;function square(e){return e*e}console.log(square(x));

Angular does this for us in production mode.

Sourcemaps

Sourcemaps allow your browser development tools to interpret non-javascript source code into the javascript that the browser runs natively. In our case, that means that there is a sourcemap file that tells the browser what lines of TypeScript coincide with the javascript that the browser is executing. Here’s an example:

To see what these look like, run ng build --output-path ./build and explore the .map files in that directory. They are not user friendly files, but you will probably be able to deduce what is going on inside the file if you look at both those, and the javascript files.

Development JS hooks

Any debug JS hooks there to allow developers access to the operating client code will be removed. This is usually less noticeable, but Angular has several tools that you can use in the browser console to control the site you are building. Using the production build mode prevents these from existing in the target code.

Outputting actual source

Use ng build and its subcommands to output the actual source. Let’s explore the build command some more. If we issue the ng build --help command, we can see everything it can do. This is a big daunting list, but I’ve abbreviated a few things to explore below.

$ ng build --help
Compiles an Angular app into an output directory named dist/ at the given output path. Must be executed from within a workspace directory.
usage: ng build <project> [options]

arguments:
  project
    The name of the project to build. Can be an application or a library.

options:

# ...

  --delete-output-path
    Delete the output path before building.
  --deploy-url
    URL where files will be deployed.

# ...

  --help
    Shows a help message for this command in the console.

# ...

  --index
    Configures the generation of the application's HTML index.
  --lazy-modules
    List of additional NgModule files that will be lazy loaded. Lazy router modules will be discovered automatically.

# ...

  --optimization
    Enables optimization of the build output.
  --output-hashing
    Define the output filename cache-busting hashing mode.
  --output-path
    The full path for the new output directory, relative to the current workspace.
    By default, writes output to a folder named dist/ in the current project.

# ...

  --prod
    Shorthand for "--configuration=production".
    When true, sets the build configuration to the production target.
    By default, the production target is set up in the workspace configuration such that all builds make use of bundling, limited tree-shaking, and also limited dead code elimination.
  --progress
    Log progress to the console while building.

# ...

  --source-map
    Output sourcemaps.

# ...

  --verbose
    Adds more details to output logging.
  --watch
    Run build when files change.

# ...

The webserver

We will address hosting in the next session. For now, it is important to know that Angular expects the web server to act in a bizarre way compared to a normal server. All 404 requests must be redirected to the index.html file instead of the server issuing a 404 header and a not found page. Go ahead, try accessing a page that doesn’t exist on a "normal" site: https://p422.chrissexton.org/thispagedoesnotexist. That was handled by the server, not a frontend.