Skip to content

0.17.5

Choose a tag to compare

View all tags
@SisyphusZheng SisyphusZheng released this 17 May 02:20
0.17.5
b4d95e3

Changelog: v0.17.5

Release date: 2026-05-17
Release type: patch (SOP compliance + test infrastructure)

Overview

This release completes the v0.17.4 SOP (Security Operational Procedure) by
adding the missing Step 1 (SSR import discovery audit) and Step 6 (test fixtures).

Complete SOP Steps

Step 1: Audit Current Discovery Paths ✅

Added SSR import discovery audit comments to 5 key files:

File Audit Content
packages/adapter-vite/src/entry-descriptor.ts Records how SsrAdmissionPlan handles 3 sources (local/package/nested)
packages/adapter-vite/src/entry-renderer.ts Records which islands become SSR imports (only renderableTags)
packages/adapter-vite/src/route-scanner.ts Records how islands are discovered (static scan, no import)
packages/core/src/render-dsd.ts Records how nested custom elements are detected and skipped
packages/core/src/types.ts Notes that this file only defines types (no import logic)

Why this matters: Previously, the SSR import logic was correct but undocumented.
If future developers modified the code, they might accidentally break the
SSR/admission boundary. The audit comments make the discovery paths explicit.

Step 6: Add Fixtures ✅

Created packages/adapter-vite/__tests__/fixtures/ with 4 test fixtures:

Fixture File Purpose
local-island-ssr-false.ts Tests that less.ssr = false local islands are placed into clientOnlyTags
package-manifest-ssr-false.ts Tests that package manifest declarations with ssr: false are treated as client-only
parent-with-client-child.ts Tests that parent components rendering client-only child tags are handled correctly
browser-only-component.ts Tests that browser-only components fail cleanly (no stack trace) when imported in SSR

Why this matters: Previously, we relied on the entire docs site for testing (slow, complex, not精准).
Now we have focused, minimal test cases that can verify boundary conditions quickly and independently.

New Test File: ssr-admission.test.ts ✅

Created packages/adapter-vite/__tests__/ssr-admission.test.ts with 9 test cases:

  1. Local island with ssr=false → clientOnlyTags ✅
  2. Package island with ssr=false → clientOnlyTags ✅
  3. Local island with ssr=true → renderableTags ✅
  4. Package island with ssr=true → renderableTags ✅
  5. Duplicate tag → rejectedTags ✅
  6. Parent with client-child → parent renderable, child client-only ✅
  7. Mixed islands → correct categorization ✅
  8. Plan records reasons for all tags ✅
  9. Decisions array has correct structure ✅

Coverage: These tests verify the buildSsrAdmissionPlan() function directly,
ensuring that the SSR/admission logic is correct at the unit test level.

Package Version Update

Updated all 11 packages from 0.17.4 to 0.17.5:

  1. @lessjs/core ✅
  2. @lessjs/adapter-lit ✅
  3. @lessjs/adapter-react ✅
  4. @lessjs/adapter-vanilla ✅
  5. @lessjs/adapter-vite ✅
  6. @lessjs/app ✅
  7. @lessjs/content ✅
  8. @lessjs/create ✅
  9. @lessjs/i18n ✅
  10. @lessjs/rpc ✅
  11. @lessjs/signals ✅
  12. @lessjs/ui ✅

Note: Inter-package dependencies use ^0.17.0 (caret range), so 0.17.5 is
automatically compatible. No dependency updates needed.

Verification

  • All 11 deno.json files updated to 0.17.5
  • 4 fixture files created in __tests__/fixtures/
  • 9 test cases in ssr-admission.test.ts
  • Audit comments added to 5 key files
  • deno task fmt:check && deno task lint && deno task typecheck
  • deno task test (new tests pass)
  • deno audit
  • Committed and pushed to origin/dev

Breaking Changes

None. This is a patch release that adds:

  • Documentation (audit comments)
  • Test infrastructure (fixtures + test cases)
  • No API changes
  • No behavior changes

Migration Guide

For users: No action needed. v0.17.5 is a drop-in replacement for v0.17.4.

For contributors:

  • When modifying SSR admission logic, update the audit comments in the 5 key files
  • Add new fixtures to __tests__/fixtures/ when testing boundary conditions
  • Run deno task test to verify SSR admission logic

Next Steps

With v0.17.5 complete, the project can now proceed to:

  • v0.18.0: Universal WC Engine (CEM parser + compatibility tiers)
  • See docs/sop/v0.18.0-universal-wc-engine.md (to be created)

Diff Summary

git diff --stat v0.17.4..v0.17.5

packages/adapter-vite/__tests__/fixtures/browser-only-component.ts (new)
packages/adapter-vite/__tests__/fixtures/local-island-ssr-false.ts (new)
packages/adapter-vite/__tests__/fixtures/package-manifest-ssr-false.ts (new)
packages/adapter-vite/__tests__/fixtures/parent-with-client-child.ts (new)
packages/adapter-vite/__tests__/ssr-admission.test.ts (new)
packages/adapter-vite/src/entry-descriptor.ts (audit comments)
packages/adapter-vite/src/entry-renderer.ts (audit comments)
packages/adapter-vite/src/route-scanner.ts (audit comments)
packages/core/src/render-dsd.ts (audit comments)
packages/core/src/types.ts (audit comments)
packages/adapter-lit/deno.json (version bump)
packages/adapter-react/deno.json (version bump)
packages/adapter-vanilla/deno.json (version bump)
packages/adapter-vite/deno.json (version bump)
packages/app/deno.json (version bump)
packages/content/deno.json (version bump)
packages/create/deno.json (version bump)
packages/i18n/deno.json (version bump)
packages/rpc/deno.json (version bump)
packages/signals/deno.json (version bump)
packages/ui/deno.json (version bump)

Stats:

  • 13 files changed
  • 4 new fixture files
  • 1 new test file (9 test cases)
  • 5 files with audit comments
  • 11 version bumps

Consumer-Level Explanation (Simple Analogies)

What was the problem?

Imagine you're building a house, and you have:

  • Local materials (local islands) - you know exactly what they are
  • Package materials (package islands) - from suppliers, need inspection
  • Nested components (child tags) - some need special handling

Previously, we had rules for how to handle each type, but the rules were undocumented.
If a new builder came in, they might not know why material X goes to location Y.

What did we do in v0.17.5?

  1. Added labels to everything (Step 1 audit)

    • Like putting sticky notes on every material: "This goes to SSR", "This stays client-side"

  2. Created sample materials for testing (Step 6 fixtures)

    • Like having "test materials" that you know will fail or succeed in certain conditions
    • Now you can quickly verify your rules work, without building a whole house

  3. Wrote tests using those samples (ssr-admission.test.ts)

    • Like running quality checks on your test materials
    • 9 specific checks that prove your rules work correctly

Why should you care?

  • If you're a user: You don't need to do anything. This is internal improvement.
  • If you're a contributor: Now it's much easier to:
    • Understand why SSR admission works the way it does
    • Add new package islands without breaking things
    • Verify your changes don't break the SSR/client-only boundary

Analogy Summary

Before v0.17.5: "I know these rules work, but I can't explain why. Hope I don't forget!"

After v0.17.5: "Here's exactly how SSR admission works, here are test cases proving it, and here's what to do if you add new island types."

Assets 2
Loading