DrewML / scd

Fast, drop-in replacement for Magento's Static Content Deploy (WIP)

scd

Fast, drop-in replacement for Magento's Static Content Deploy

Why?

For background on the motivations for the scd project, please see the original proposal.

How to use

This project is not quite ready yet, and many features from Magento core are not supported just yet. If you want to live on the bleeding edge, you can follow the developer instructions below.

How to work on scd

1. Ensure you have a version of node.js locally that is >= v10.12.0
2. Clone the repository
3. In the root, run npm install
4. Run npm test to verify you've set everything up properly. All tests are expected to pass

How to run against a store locally

1. Run npm link in the root of this repository once. This will add the global scd command to your $PATH

You can now run scd in the root directory of any Magento 2 store locally.

What works for far?

Only one scenario has been tested and developed against so far. This is:

• Stock store on 2.3-develop
• Using Luma
• Only targeting en_US

Things that have not been tested yet:

• Translations (they're not even implemented, so they surely don't work)
• adminhtml theme(s) (they might work, but I haven't tested)
• Deploying multiple themes at once. It might work (untested), but they're currently processed serially

Should I use this for Production?

You're probably not going to listen to me, but I wouldn't just yet.

Unsupported Features

See UNSUPPORTED.md

Design Goals

• Favor speed over memory consumption always. Memory is cheap, time is not
• (Except in rare cases) data structures passed between module boundaries should be limited to those that can be easily serialized to JSON. This keeps it possible to move modules to a worker or use caches for only certain tasks later.
• Always favor optimizing code over caching
  • Only add caching in places where slow things cannot otherwise be sped up
  • Caches are always a bug farm in build tools
• Thoroughly loggable/traceable
• As much of the code base should be stateless as possible. Keep state confined to well-defined areas
• Keep root path handling separate from relative path handling
  • Any persistent caching should work even when store is moved to another dir on disk or copied to another fs
• Compiled/released version should be compatible with Windows, but only *nix compat is fine for building the project and running tests