Skip to content

Releases: numelon-oss/sklair

v0.3.0

24 Jan 00:05
@github-actions github-actions
v0.3.0
53203d9

Choose a tag to compare

View all tags
v0.3.0 Latest
Latest

Sklair 0.3.0 👽

Sklair 0.3.0 focuses on stability, tooling, and correctness, especially around build hooks and project configuration with sklair.json.

What changed? 🍉

Fixed Lua JSON library registration

  • The json module is now correctly registered in the sandboxed Lua environment
  • Hooks relying on JSON encoding/decoding now work as intended

Formalised sklair.json configuration + schema

  • JSON Schema is automatically generated now for sklair.json (project configuration)
  • $schema is now included in generated configs so that autocompletion in editors is possible
  • Disabled features no longer appear in generated config files as empty JSON objects

Improved hooks configuration

  • hooks is now a structured, optional config section
    • This doesn't actually mean anything yet - the type of hooks was changed from string to object, in line with our goal of extending hooks once again with a new HTTP library, but other than that, any fields populated inside this hooks object currently will not affect any builds until 0.4.0.

Fixed a wrong error message

  • When using the fs library in hooks, one might be presented with an error message that shows wrong information when an incorrect path prefix is used.
    • Specifically, an error message said that the prefix temporary should be used, when in reality the actual prefix is temp.

What's next?

In 0.4.0, what is to be expected is definitely a safe, sandboxed HTTP library for hooks. Additional features may include document-wide compiler directives (as opposed to ones that only work in <head>, like now) because of a compiler directive engine, and maybe some component dynamism through logic inside of comments.

In the slightly longer term, what is to be expected is component nesting with circular dependency detection, dynamic resource hints, full Lua block support everywhere, and finally distribution of Sklair via package managers like homebrew, winget, and maybe apt.

In the even longer term, a GitHub action may be created to streamline the building and publishing of Sklair websites onto GitHub pages. But for now, regular GitHub workflows are good enough.

Assets 9
Loading

v0.2.0

11 Jan 17:32
@github-actions github-actions
v0.2.0
2e0101f

Choose a tag to compare

View all tags
v0.2.0

Sklair 0.2.0 👾

Sklair 0.2.0 focuses on build extensibility, sandboxing, and a more reliable development workflow.

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.

What's new? 🐸

Pre- and post-build hooks

Projects can now define Lua scripts that run:

  • before Sklair builds a site, and
  • after Sklair finished building

These hooks are intended for things like generating data files, transforming assets, or preparing or post-processing build output.

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.

Note

Hooks run in a deliberately restricted Lua sandbox. There is no coroutine support because hooks are intended to be simple, deterministic, and strictly sequential.

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.

If you believe coroutines are genuinely required for a real-world build workflow (and not just for convenience), feel free to open an issue and make the case. I am happy to revisit this design if it proves justified.

Sandboxed filesystem for hooks

Functions in fs.*

  • fs.read(path) - reads an entire file and returns contents (string) on success, or nil, errMsg (string) on failure.
  • fs.write(path) - writes an entire file and returns true on success, or nil, errMsg (string) on failure.
  • 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.

Lua hooks use Sklair's filesystem API instead of direct OS access, where paths are scoped by prefix:

Prefix Purpose
project: Read-only access to source files
cache: Persistent cache between builds and hooks
temp: Temporary workspace
generated: Artefacts produced by pre-build hooks
built: Final site output (post-build only)

sklair clean

A new, simple command to remove:

  • cached data
  • temporary files
  • generated artefacts

Improved sklair serve

The development server now behaves properly in projects:

  • filesystem watching is debounced
  • build state (.sklair/) is excluded from watching, to prevent self-triggered rebuild loops
  • The implementation of this command is no longer a "quick solution", but rather properly refined

Internal build system improvements

  • clearer timing output when in debug verbosity
  • 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.

What's next?

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.

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.

Loading

v0.1.0

03 Jan 22:39
@github-actions github-actions
v0.1.0
7e5cb3b

Choose a tag to compare

View all tags
v0.1.0

Sklair 0.1.0 🎉

HTML deserved better.

This is the first official release of Sklair - a compiler that brings structure, composability, and performance back to plain HTML without turning the web into a JavaScript framework.

What's included in v0.1.0 🥹

This release is a bit more than just a prototype, its a complete pipeline that works. But as always, improvements can be made.

Component system

  • HTML files act as components
  • Components can define both <head> and <body> content
  • Head nodes are automatically deduplicated across components
  • Components are cached lazily for performance

Heuristic head ordering pass

Sklair doesn’t just concatenate <head> tags, it understands them.

  • Nodes are classified (charset, viewport, styles, scripts, analytics, SEO, etc.)
  • They are sorted into an optimal order
  • Duplicates are removed using structural hashing
  • Social meta (OpenGraph + Twitter) and others which have no effect on what a user sees at all is grouped and placed at the end

Ordering barriers

During the head ordering pass, some things might break if they are moved around in the wrong order.

The best example I can think of is importing cdn.tailwindcss.com and needing tailwind.config to come after the TailwindCSS script is imported, not before.

Some things must stay together. Sklair lets you enforce that.

<!-- sklair:ordering-barrier treat-as=dont-care -->
<meta property="og:title" …>
<meta name="twitter:title" …>
<!-- sklair:ordering-barrier-end -->

Sklair will keep those nodes together while still optimising everything else.

sklair:remove

You can include tags for editor previews that will never ship:

<!-- sklair:remove -->
<script src="https://cdn.tailwindcss.com"></script>
<!-- sklair:remove-end -->

This is perfect for things like component previews in VSCode without polluting production builds.

gitignore-style excludes

No more ugly **/**/**, Sklair now accepts gitignore-style excludes which are automatically normalised to doublestar globs.

"exclude": [
  ".git",
  "node_modules",
  ".env*",
  "*.psd",
  "!important.psd"
]

sklair serve

A real development server with file watching via fsnotify, automatic rebuilds, websocket-based live reload, and support for custom user-created 404 pages.

Proper CLI

  • sklair build
  • sklair config
  • sklair docs
  • sklair init
  • sklair serve
  • sklair version
  • Global --debug, --verbose, --silent verbosity flags

Note that the verbosity flags must come before any command. E.g. sklair --debug build.

Whats next

0.1.0 is the foundation, for now. Coming next will be component nesting, circular dependency detection, dynamic resource hints, full Lua block support, a stable pre/post-build hook system, and finally distribution of sklair via package managers like brew, winget and maybe apt.

HTML deserved better.
Now it has Sklair.

Loading