sku

sku is a front-end development toolkit designed for zero-config builds, local development, testing, and linting. It provides sensible defaults for production-ready environments and is specifically tuned for use within SEEK ecosystems.

Key features include:

• Zero-config builds: Out-of-the-box support for Webpack or Vite. You only need to add a sku.config file when opting into advanced configurations.
• Production readiness: Built-in support for code splitting, multi-site theming, and Content Security Policy (CSP).
• Integrated quality tools: Pre-configured support for ESLint, Prettier, TypeScript, and Vitest.
• SEEK ecosystem compatibility: First-class support for Braid Design System, Vanilla Extract, and Vocab.

The @sku-lib/babel-plugin-display-name Babel plugin ensures that the displayName property is added to React components in all environments.

Unlike the original MUI version, which wraps the displayName addition in a process.env.NODE_ENV check (omitting it in production), this fork removes that check. Use this plugin if your application or debugging tools require the displayName property to be present even in production builds.

Since v15, sku supports Vite as an alternative to the Webpack bundler.

Limitations:

• Vite support is currently only available for static applications (SSG).
• Supported commands: sku start and sku build.
• sku serve is also available as it is bundler agnostic.

Library Mode: Building libraries with Webpack is currently supported, but this feature is planned for deprecation and will not be supported with Vite. A migration guide for sku libraries will be provided in the future.

By default, sku uses Vitest's configuration where global test APIs (like describe, it, expect) are disabled. You must explicitly import these from vitest in your test files.

Additionally, because globals are disabled, libraries like @testing-library/react will not perform automatic DOM cleanup. You must manually add cleanup to your setupTests file using afterEach from vitest.

// myFunction.test.ts
import { describe, expect, it } from 'vitest';

// test-setup.ts
import '@testing-library/jest-dom/vitest';
import { cleanup } from '@testing-library/react';
import { afterEach } from 'vitest';

afterEach(cleanup);

You can manage local development hostnames using the following mechanisms:

• Automatic Resolution: Use *.localhost or localhost to avoid manual /etc/hosts configuration and suppress warnings.
• sku setup-hosts: When running this command, sku will continue to write .localhost hosts to your hosts file (except for the exact localhost hostname, which is skipped to avoid duplication).
• HTTPS Support: For browsers like Safari that may still require local SSL, existing httpsDevServer and local HTTPS behaviors remain fully supported and functional.

Unlike other images, imported SVGs are treated as raw strings containing optimized (via SVGO) markup rather than URLs. You can render this markup using dangerouslySetInnerHTML in React.

Important: To ensure consistent behavior between Webpack and Vite, it is recommended to use query parameters (url, raw, or inline) when importing SVGs. Without these, Webpack returns optimized markup while Vite treats them as standard image assets (URLs/data URLs).

import svgMarkup from './icon.svg';

const MySvgComponent = () => {
  return <div dangerouslySetInnerHTML={{ __html: svgMarkup }} />;
};

By default, sku uses babel-plugin-unassert to remove assertions from your production builds. This allows you to use expensive runtime checks in development without impacting production performance.

Supported Assertion Functions:

• invariant
• assert

Supported Libraries:

• tiny-invariant (Recommended)
• assert (Browser port)
• node:assert (Node.js built-in)
• assert (Node.js built-in)

import React from 'react';
import assert from 'assert';

export const Rating = ({ rating }: { rating: number }) => {
  assert(rating >= 0 && rating <= 5, 'Rating must be between 0 and 5');

  return <div...>{
}

import React from 'react';

export const Rating = ({ rating }) => {
  return <div...>;
}

To avoid duplicating translations for similar languages, you can use language extensions. If a language extends another, sku will automatically copy any missing translations from the base language to the specific language.

Example: An en-AU language can extend en to only provide specific spelling differences (like colour vs color).

Warning: Avoid using extensions if you are not certain you want the base language's translations to fall back to production, as sku cannot distinguish between an intentional omission and a mistake.

// Example of a language object designating a parent
{ name: "en-AU", extends: "en" }

During development, sku runs two distinct services:

1. Dev Server: Responsible for serving static assets. It acts as the primary entrypoint and proxies requests that do not match known static routes to the SSR service. This simulates a production reverse-proxy environment and avoids CORS issues.
2. SSR Service: Runs your application's server code.

If you need to proxy other traffic, such as API requests, you should use [Dev Server Middleware].

sku applications rely on specific entry points depending on their rendering strategy:

• Render Entry: Used in static rendering. It returns an HTML string representing routes, sites, and environments. It functions like a server render that executes at build time.
• Server Entry: Used in SSR only projects. It handles HTTP requests (using express) and allows for router middleware. It is similar to the Render entry but operates during request time.
• Client Entry: The entry point for all browser-side code. This is where you hydrate your React application and configure state management.