meld-spec

Types

The meld-spec package exports the following key types:

$3

- MeldNode - Base interface for all AST nodes
- DirectiveNode - AST node for directives
- TextNode - AST node for text content
- CodeFenceNode - AST node for code fences
- VariableNode - AST node for variables
- ErrorNode - AST node for errors
- TextVarNode - AST node for text variables (${identifier})
- DataVarNode - AST node for data variables (#{identifier})
- PathVarNode - AST node for path variables ($identifier)
- CommentNode - AST node for comments

$3

- StructuredPath - Enhanced path representation for file-based directives
- raw - Original path string as written in the document
- normalized - Normalized form of the path (e.g., with leading ./)
- structured - Parsed path components
- base - Base directory or special path (e.g., ., $HOMEPATH)
- segments - Array of path segments
- variables - Map of variables used in the path
- cwd - Optional boolean flag for path type:
- true for paths without slashes (e.g., file.md, ${file_path})
- false for paths with slashes (e.g., path/to/file.md)
- Defaults to false when omitted

$3

- SourceLocation - Location information for nodes
- DirectiveData - Base interface for directive data
- DirectiveKind - Union type of all directive kinds
- MultiLineBlock - Structure for multi-line content

$3

- CommandDefinition - Definition of a command
- CommandMetadata - Metadata for commands
- RiskLevel - Risk level for commands ('high' | 'med' | 'low')

$3

- Parser - Interface that all Meld parser implementations must implement
- ParserTestCase - Structure for parser test cases

$3

- ValidationError - Structure for validation errors
- ValidationContext - Context for validation
- ValidationResult - Result of validation
- Example - Structure for test examples

Updates

We've enhanced the error handling specification to better support both user-friendly errors and detailed debugging. The key changes are:

1. ErrorNode now includes an optional debugDetails field for implementation-specific error details
2. Standard error messages (in error field) remain unchanged and are used for test comparisons
3. When in debug mode, you should format errors as: error + '\n' + debugDetails

This means you can keep your detailed PEG.js (or other parser) error messages - just put them in debugDetails instead of the main error message. This gives users the best of both worlds: clean errors by default, with the option to see technical details when needed.

Example:
``typescript
// Your error node might look like:
{
type: 'Error',
error: 'Empty path in @import directive', // Standard message from spec
debugDetails: 'Expected \'[\' or [^#[\\]] but \']\' found' // Your parser's details
}
`

The test suite will only check the error field, so you're free to include whatever debugging info is most helpful in debugDetails.

Implementing the Specification

To implement the Meld specification, you'll need to:

1. Import the types and implement the Parser interface:
`typescript
import { Parser, MeldNode, DirectiveNode } from 'meld-spec';

class MyMeldParser implements Parser {
parse(input: string): MeldNode[] {
// Your implementation here
}
}
`

2. Import and use the test cases:
`typescript
// Import specific test cases
import {
dataTests,
dataInvalidTests,
textTests,
textInvalidTests,
runTests,
runInvalidTests,
embedTests,
embedInvalidTests,
// ... other test imports
} from 'meld-spec';

// Import validation utilities
import { validateSyntax } from 'meld-spec';

// Test your implementation
const parser = new MyMeldParser();
const result = validateSyntax({ parser }, dataTests);
expect(result.valid).toBe(true);
`

The specification tests define both valid and invalid cases for each feature. Your implementation should:
- Match the expected AST structure for valid cases
- Produce appropriate errors for invalid cases

Error Handling

The Meld specification defines a standard approach for error handling across all implementations:

$3

`typescript
interface ErrorNode {
type: 'Error';
error: string; // User-friendly error message
debugDetails?: string; // Optional technical details for debug mode
partialNode?: MeldNode;// Optional partial AST if available
}
`

$3

1. Standard Error Messages
- Implementations MUST use the standard error messages defined in the test files
- Error messages should be user-friendly and descriptive
- Examples:
- "Empty path in @import directive"
- "Data variables not allowed in import path"

2. Debug Mode
- Implementations SHOULD support a debug mode
- In debug mode, errors should include both standard message and technical details
- Format: error + '\n' + debugDetails
- Example:
`
// Normal mode:
Empty path in @import directive

// Debug mode:
Empty path in @import directive
Expected '[' or [^#[\\]] but ']' found
`

3. Implementation Details
- Debug details are implementation-specific
- Can include parser errors, stack traces, or any helpful debugging information
- The debugDetails field is optional but recommended
- Debug information should be appended after the standard error message

4. Comparison Behavior
- When comparing error nodes (e.g., in tests), only the error field is compared
- The debugDetails field is ignored during comparisons
- This allows implementations to provide rich debug information while maintaining compatibility

5. Partial AST
- When possible, implementations should provide a partial AST in the partialNode` field
- This can help with error recovery and providing better error messages
- The partial AST is optional and not used in error comparisons