-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Asset Loading #518
Labels
Comments
delambo
added a commit
that referenced
this issue
Aug 4, 2017
delambo
added a commit
that referenced
this issue
Aug 10, 2017
* adds static asset support #518 * fixes assets manifest merging; fixes server public assets in dev; fixes static starter script order alpha.2 published
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 intobuild/public
on thebuild
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
wrapsfile-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
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 loadingjs
andcss
extensions.the file-loader will be configured to fingerprint assets and output files with the following name format:
[name]-[hash].[ext]
the file-loader will be configured so that assets from the client and server builds will be output to
build/public
.the assets manifest will include mappings of the fingerprinted assets to their original file names from the client and server builds
other loaders will be configured to
exclude
any imports from thesrc/public
directory.Drawbacks
Alternatives
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
The text was updated successfully, but these errors were encountered: