Page MenuHomePhabricator

Assets should differentiate between built and source
Closed, ResolvedPublic


When managing assets for a project, most of them are treated in some way before deployment. Here are some examples:

  • Images are compressed and optimized for the web. JPEGs could also be converted into WEBP, PNGs can be optimized via quantization to generate huge performance wins
  • scss files can be compiled and somewhat minified to reduce the load
  • js files can be minified, reducing their footprint significantly

Currently, we always place these files directly in their corresponding /assets folder, for example /assets/js. Making it somewhat harder for applications to make a distinction between compiled and minified and source.

Most often, the approach I've seen is to use an addition to the extension, like /assets/js/myjs.min.js, but using something like /assets/deploy/js/my.js, or even /assets/deploy/20191125/js/my.js makes it incredibly easy to:

  1. Invalidate caches on CDNs, since the entire path has changed
  2. Rewrite the file names between staging, and production.

The code in our URL::asset function, just adds the base_url and /assets to the parameter it receives. Configuring the /assets part should be trivial, and have virtually no impact in the performance of the application, while being dead-simple to configure.

An automatically generated environments file could contain information on where the building tools placed, or should place, the built files.

Event Timeline

cesar triaged this task as High priority.Dec 5 2019, 12:01 PM
cesar created this task.
cesar created this object with visibility "Public (No Login Required)".
cesar added a parent task: Unknown Object (Maniphest Task).Dec 23 2019, 10:30 AM

I have a few gripes with the way this works, but for now, it should be providing a basic API to be iterating upon.
The system allows building assets by checking the extension, and will compile scss, js, png and jpeg - all other file types will just be mindlessly moved to the build directory.

With every one of these releases, Spitfire applications are becoming more 'compiled'. A Spitfire app now can't be deployed from a repository by just cloning it, but instead the app gets deployed on the server, assets build, dependencies checked and databases set-up. While this is a departure from the run-n-gun approach we had up until now, it should provide a safe balance between ease of set-up (a Spitfire application should take no more than a minute or two to deploy to production) and consistent set ups (I hate finding out hours later that GD is not working properly, or that we should have added imagemagik to the mix).

cesar closed this task as Resolved.Apr 30 2020, 12:19 PM