|
| 1 | +# Sklair 0.2.0 👾 |
| 2 | + |
| 3 | +Sklair 0.2.0 focuses on build extensibility, sandboxing, and a more reliable development workflow. |
| 4 | + |
| 5 | +This release includes **pre- and post-build hooks** with a **sandboxed Lua environment** (for scripting), and major improvements to `sklair serve` along with a new `sklair clean` command. |
| 6 | + |
| 7 | +## What's new? 🐸 |
| 8 | + |
| 9 | +### Pre- and post-build hooks |
| 10 | + |
| 11 | +Projects can now define Lua scripts that run: |
| 12 | + |
| 13 | +- **before** Sklair builds a site, and |
| 14 | +- **after** Sklair finished building |
| 15 | + |
| 16 | +These hooks are intended for things like generating data files, transforming assets, or preparing or post-processing build output. |
| 17 | + |
| 18 | +Hooks run in a **sandboxed Lua environment** with a controlled filesystem API, so they can do useful work without having unrestricted access to your system. |
| 19 | + |
| 20 | +> [!NOTE] |
| 21 | +> Hooks run in a deliberately restricted Lua sandbox. There is no coroutine support because hooks are intended to be simple, deterministic, and strictly sequential. |
| 22 | +> |
| 23 | +> The goal of hooks is data preparation and build-time transformation - not background tasks or schedulers, etc. To support that, Sklair provides only what is actually needed, such as filesystem access, JSON, and a few other things. |
| 24 | +> |
| 25 | +> If you believe coroutines are genuinely required for a real-world build workflow (and not just for convenience), feel free to [open an issue](https://github.com/numelon-oss/sklair-cli/issues) and make the case. I am happy to revisit this design if it proves justified. |
| 26 | +
|
| 27 | +### Sandboxed filesystem for hooks |
| 28 | + |
| 29 | +### Functions in `fs.*` |
| 30 | + |
| 31 | +- `fs.read(path)` - reads an entire file and returns `contents (string)` on success, or `nil, errMsg (string)` on failure. |
| 32 | +- `fs.write(path)` - writes an entire file and returns `true` on success, or `nil, errMsg (string)` on failure. |
| 33 | +- `fs.scandir(path)` - scan an entire directory and returns a `table` containing entries with fields `name (string)` and `isDir (boolean)` on success, or `nil, errMsg (string)` on failure. |
| 34 | + |
| 35 | +Lua hooks use Sklair's filesystem API instead of direct OS access, where paths are scoped by prefix: |
| 36 | + |
| 37 | +| Prefix | Purpose | |
| 38 | +|--------------|-------------------------------------------| |
| 39 | +| `project:` | Read-only access to source files | |
| 40 | +| `cache:` | Persistent cache between builds and hooks | |
| 41 | +| `temp:` | Temporary workspace | |
| 42 | +| `generated:` | Artefacts produced by pre-build hooks | |
| 43 | +| `built:` | Final site output (post-build only) | |
| 44 | + |
| 45 | +### `sklair clean` |
| 46 | + |
| 47 | +A new, simple command to remove: |
| 48 | + |
| 49 | +- cached data |
| 50 | +- temporary files |
| 51 | +- generated artefacts |
| 52 | + |
| 53 | +### Improved `sklair serve` |
| 54 | + |
| 55 | +The development server now behaves properly in projects: |
| 56 | + |
| 57 | +- filesystem watching is debounced |
| 58 | +- build state (`.sklair/`) is excluded from watching, to prevent self-triggered rebuild loops |
| 59 | +- The implementation of this command is no longer a "quick solution", but rather properly refined |
| 60 | + |
| 61 | +### Internal build system improvements |
| 62 | + |
| 63 | +- clearer timing output when in debug verbosity |
| 64 | +- ***much* faster static file copying**, thanks to switching from `os.ReadFile` (a full in-memory load) to streaming with `io.Copy`, which avoids buffering entire files in RAM. |
| 65 | + |
| 66 | +## What's next? |
| 67 | + |
| 68 | +0.2.0 changes Sklair from something that compiles HTML and components, into something that can now run sandboxed logic before and after building, and has a reliable live development server. Essentially a build system. |
| 69 | + |
| 70 | +Coming next will be component nesting with circular dependency detection, dynamic resource hints, full Lua block support, and finally distribution of Sklair via package managers like homebrew, winget, and maybe apt. |
0 commit comments