RFC: Asset Loading

[delambo]

Summary

kyt has basic static asset support but it's missing some advanced use cases. This RFC is a proposal to refactor asset loading so that it supports asset fingerprinting and loading assets from inside and outside of the public directory.

Motivation

Static asset support is common in web frameworks (see Rails and Vue). kyt has some static asset support but it's limited. Unfortunately, we found that out in our internal project as we had to hack in additional support. Now that it has been battle tested, we should migrate some of the advanced support from our project into kyt.

As mentioned, kyt already supports a static directory, src/public, which is copied into build/public on the build command. This is a good pattern for both universal and static apps that need to load and serve static assets from an absolute path or read assets from the file system.

One feature missing from kyt's asset handling is fingerprinting. Fingerprinting is a popular pattern for invalidating caches. A kyt user should be able to import an asset and expect it to be renamed with a hash by the build and copied into src/public.

The last motivation for refactoring static assets is to remove the url-loader. url-loader wraps file-loader and inlines assets as datauri. Since we're using/strongly recommending http2 we should drop support for the old http1 datauri inlining pattern.

Detailed design

1. kyt will use a file-loader to load files with the following asset extensions in the src directory:

jpg|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga|ico

Inside of the src/public directory kyt will additionally support file loading js and css extensions.

2. the file-loader will be configured to fingerprint assets and output files with the following name format: [name]-[hash].[ext]

3. the file-loader will be configured so that assets from the client and server builds will be output to build/public.

4. the assets manifest will include mappings of the fingerprinted assets to their original file names from the client and server builds

5. other loaders will be configured to exclude any imports from the src/public directory.

Drawbacks

1. kyt users that are stuck on http1 and rely on datauri inlining as a performance enhancement may pay a penalty if they request a lot of assets from the same domain. It's hard to weigh the tradeoff as datauri inlining comes with its own penalty by increasing the asset size by 37%.

Alternatives

1. Write our own file-loader. We're stuck on an older version of file-loader as the most recent version has a bug that we can't work around (here's another one). To make matters worse, file-loader is hard to work with in an isomorphic environment because it respects the server build output.path and hardcodes that into the file resolution. For now, I think I found a way to hack around that problem but kyt has some specific asset loading use cases that might be easier to handle on our own.

Unresolved questions

not sure of any right now