CtrlK
BlogDocsLog inGet started
Tessl Logo

tessl/npm-jsii-diff

Assembly comparison for jsii that detects breaking changes and compatibility violations between library versions

Pending
Quality

Pending

Does it follow best practices?

Impact

Pending

No eval scenarios have been run

SecuritybySnyk

Pending

The risk profile of this skill

Overview
Eval results
Files

assembly-comparison.mddocs/

Assembly Comparison

Core API for comparing two jsii assemblies to detect breaking changes and compatibility violations between library versions. This provides the foundational functionality for validating API evolution and ensuring backward compatibility.

Capabilities

Compare Assemblies Function

The primary function for comparing two jsii assemblies for API compatibility.

/**
 * Compare two assemblies for compatibility
 * 
 * Checks whether code written against the original assembly will still
 * typecheck when compiled against the updated assembly. Validates that:
 * - All types in original still exist in updated
 * - Enums have only added members  
 * - Classes/interfaces have only added members or allowed modifications
 * - Property types are same or strengthened
 * - Method arguments only added optional, existing weakened, return strengthened
 * 
 * @param original - The original assembly to compare from
 * @param updated - The updated assembly to compare to  
 * @param options - Configuration options for comparison
 * @returns Mismatches object containing any compatibility violations
 */
function compareAssemblies(
  original: reflect.Assembly,
  updated: reflect.Assembly,
  options?: ComparisonOptions
): Mismatches;

Usage Examples:

import { compareAssemblies } from "jsii-diff";
import * as reflect from "jsii-reflect";

// Compare two local assemblies
const ts1 = new reflect.TypeSystem();
const original = ts1.loadModule("./packages/my-lib");

const ts2 = new reflect.TypeSystem();
const updated = ts2.loadModule("./packages/my-lib-v2");

const mismatches = compareAssemblies(original, updated);

// Check for any compatibility issues
if (mismatches.count > 0) {
  console.log(`Found ${mismatches.count} compatibility issues:`);
  for (const message of mismatches.messages()) {
    console.log(`- ${message}`);
  }
}

// Compare with custom options
const mismatchesExperimental = compareAssemblies(original, updated, {
  defaultExperimental: true // treat unmarked APIs as experimental
});

Comparison Options

Configuration interface for customizing assembly comparison behavior.

/**
 * Configuration options for assembly comparison
 */
interface ComparisonOptions {
  /** 
   * Whether to treat API elements as experimental if unmarked
   * When true, unmarked APIs are treated as experimental (more lenient rules)
   * When false, unmarked APIs are treated as stable (stricter rules)
   * @default false (treat as stable)
   */
  defaultExperimental?: boolean;
}

Mismatches Collection

Container for collecting and managing API compatibility violations during comparison.

/**
 * Collection of API compatibility mismatches with reporting capabilities
 */
class Mismatches implements IReport {
  /** Array of all collected compatibility violations */
  readonly mismatches: Array<ApiMismatch>;
  
  /**
   * Create a new mismatches collection
   * @param opts - Configuration including default stability level
   */
  constructor(opts: { defaultStability: Stability });
  
  /**
   * Report a new API compatibility violation
   * @param options - Details of the violation to report
   */
  report(options: ReportOptions): void;
  
  /**
   * Iterate over all mismatch messages
   * @returns Iterator of human-readable violation messages
   */
  messages(): IterableIterator<string>;
  
  /** Total number of compatibility violations found */
  readonly count: number;
  
  /**
   * Create filtered copy of mismatches based on predicate
   * @param pred - Function to test each mismatch
   * @returns New Mismatches instance with filtered results
   */
  filter(pred: (x: ApiMismatch) => boolean): Mismatches;
  
  /**
   * Create reporter with additional context for all future reports
   * @param motivation - Context string to append to violation messages
   * @returns New reporter with motivation context
   */
  withMotivation(motivation: string): IReport;
}

API Mismatch

Individual API compatibility violation with metadata.

/**
 * Represents a single API compatibility violation
 */
interface ApiMismatch {
  /** Human-readable description of the compatibility violation */
  message: string;
  /** Unique identifier for this violation type and element */
  violationKey: string;
  /** Stability level of the API element that has the violation */
  stability: Stability;
}

Report Options

Configuration for reporting API violations.

/**
 * Options for reporting an API compatibility violation
 */
interface ReportOptions {
  /** Identifier for the type of rule that was violated */
  ruleKey: string;
  /** The specific API element that violates compatibility */
  violator: ApiElement;
  /** Description of how the element violates compatibility */
  message: string;
}

Report Interface

Interface for components that can receive API violation reports.

/**
 * Interface for reporting API compatibility violations
 */
interface IReport {
  /**
   * Report an API compatibility violation
   * @param options - Details of the violation
   */
  report(options: ReportOptions): void;
  
  /**
   * Create a reporter with additional context
   * @param reason - Context to add to future reports
   * @returns New reporter with added context
   */
  withMotivation(reason: string): IReport;
}

Compatibility Rules

jsii-diff implements sophisticated compatibility rules based on the principle that APIs can:

  • Weaken inputs (require less from callers)
  • Strengthen outputs (guarantee more to callers)

Type Evolution Rules

  • Enums: May only add new members, never remove or modify existing ones
  • Classes/Interfaces: May add members, modify existing members only in allowed ways
  • Properties: Types may be strengthened (more restrictive)
  • Methods: May add optional parameters, weaken existing parameter types, strengthen return types

Stability-Based Rules

Different rules apply based on API stability:

  • Stable: Strict compatibility rules, breaking changes cause errors
  • Experimental: More lenient rules, breaking changes cause warnings
  • Deprecated: May be modified before removal
  • External: Compatibility depends on external library evolution

Struct vs Reference Types

  • Structs (data interfaces): Evaluated based on usage position (input/output)
  • Reference Types (classes/behavioral interfaces): May only add members by default
  • @subclassable Types: Must follow weakening rules to avoid breaking implementors

docs

assembly-comparison.md

cli.md

diagnostics.md

index.md

stability.md

utilities.md

tile.json