* fix(build): make ConfigureAwait.Fody weaving actually take effect ConfigureAwait.Fody only rewrites awaits when it is handed an explicit ContinueOnCapturedContext value. A bare <ConfigureAwait /> element parses cleanly, emits no warning, and weaves nothing. Of the 98 FodyWeavers.xml files under src/, only 22 set the attribute. The other 76 carried a bare element, so those projects compiled with no weaving at all while looking correctly configured. Verified on Debug net10.0 builds: Elsa.Secrets (attribute set) referenced ConfiguredTaskAwaitable, while Elsa.Alterations (bare element) did not. Elsa ships as a library and can be hosted where a SynchronizationContext exists, so weave everywhere rather than dropping the packages. Fody reads the WeaverConfiguration MSBuild property in preference to any FodyWeavers.xml, so the directive now lives in a single file, src/Fody.props, alongside the package references it belongs with. All 98 per-project XML files are deleted; they would otherwise be dead and misleading. src/apps has its own props root that does not chain up to src/Directory.Build.props, so it imports src/Fody.props directly instead of redeclaring the Fody package references. This second gap was found by the guard below, not by inspection. Guard: Directory.Build.targets fails the build for any project that references ConfigureAwait.Fody without an effective directive (ELSA0001) or that reintroduces a FodyWeavers.xml alongside it (ELSA0002). Both were verified to fire, including on the exact original bug shape. The 22 already-weaving projects are unaffected: their effective directive is identical before and after, and that set is disjoint from the four projects holding explicit .ConfigureAwait( calls. All 25 such calls pass false, matching what the weaver now applies, so they become redundant rather than contradictory and are left in place. Also repoints two security-assessment claims that cited the presence of FodyWeavers.xml as evidence of weaving — the inference that masked this bug. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(build): drop FodyWeavers.xml from the new UserTasks modules Merging main brought in eight new projects. Elsa.UserTasks carried a bare <ConfigureAwait /> — the same latent no-op this branch removes elsewhere, added while the fix was in review. Its seven persistence siblings set the attribute. The guard caught it: ELSA0002 failed CI on the PR merge commit for all three TFMs, on a file that never existed in the branch's own worktree. All eight are redundant now that src/Fody.props supplies the directive. Verified Elsa.UserTasks resolves it and its net10.0 build references ConfiguredTaskAwaitable. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| Ast | ||
| Compiler | ||
| Contracts | ||
| Extensions | ||
| Features | ||
| Helpers | ||
| Materializers | ||
| Parser | ||
| ShellFeatures | ||
| Elsa.Dsl.ElsaScript.csproj | ||
| README.md | ||
ElsaScript DSL Implementation
This document provides an overview of the ElsaScript DSL implementation for Elsa Workflows.
Overview
ElsaScript is a JavaScript-inspired textual DSL for authoring Elsa 3 workflows. It provides a concise, code-centric alternative to C# WorkflowBuilder APIs and JSON workflow definitions.
Features Implemented
Parser (ElsaScriptParser)
The parser uses a simplified regex-based approach to parse ElsaScript source code into an Abstract Syntax Tree (AST).
Supported Syntax:
usestatements for namespaces and expression language configurationworkflow "Name" { ... }declarations- Variable declarations:
var,let,const - Activity invocations with positional and named arguments
- Expression literals (strings, numbers, booleans, arrays)
- Expression language prefixes (
=>,js =>,cs =>,py =>,liquid =>) listenkeyword for workflow triggers (partial support)
AST Nodes
Complete set of AST node types:
WorkflowNode- Root workflow definitionStatementNodebase class with implementations:VariableDeclarationNodeActivityInvocationNodeBlockNode(for sequences)IfNode,ForEachNode,ForNode,WhileNode,SwitchNodeFlowchartNode,ListenNode
ExpressionNodebase class with implementations:LiteralNode,IdentifierNode,ArrayLiteralNodeElsaExpressionNode(with language support)TemplateStringNode,BinaryExpressionNode,UnaryExpressionNode
ArgumentNodefor activity parametersUseNodefor import/configuration statements
Compiler (ElsaScriptCompiler)
Compiles AST to Elsa workflow activities:
- Traverses AST and constructs Elsa activity graphs
- Maps DSL constructs to Elsa activities:
- Blocks →
Sequence - Variables →
Variableinstances - Activity invocations → Elsa activity instances
- Control flow nodes → corresponding Elsa activities
- Blocks →
- Resolves activities via
IActivityRegistry - Binds expressions to Elsa expression system with language support
- Maps expression languages (js, cs, py, liquid) to Elsa providers
Dependency Injection
Integration with Elsa's module system:
ElsaScriptFeaturefor service registrationModuleExtensions.UseElsaScript()for easy setup- Registers
IElsaScriptParserandIElsaScriptCompilerservices
Example Usage
use Elsa.Activities.Console;
use expressions js;
workflow "HelloWorld" {
var greeting = "Hello";
WriteLine(=> greeting + " World");
WriteLine("Great to meet you!");
}
Integration Tests
Six integration tests demonstrate the implementation:
- Parser can parse a simple workflow definition - Verifies basic workflow parsing
- Parser can parse variable declarations - Tests var/let/const parsing
- Parser can parse activity invocations with named arguments - Tests argument parsing
- Compiler service is registered and available - Verifies DI setup
- Compiler can parse and analyze a workflow AST - Tests AST analysis
- Compiler recognizes variable declarations in AST - Tests variable compilation
Known Limitations
This is a foundation implementation with several areas for future enhancement:
Parser Limitations
- Uses regex instead of Parlot for parsing (simpler but less robust)
- Control flow parsing (if/foreach/while/for/switch) needs completion
- Block/sequence parsing needs enhancement
- Flowchart syntax not yet implemented
- Template string parsing incomplete
Compiler Limitations
- Dynamic activity instantiation needs refinement
- Control flow compilation stubs need full implementation
- For loop compilation not implemented
- Flowchart compilation not implemented
- Error handling and diagnostics minimal
Runtime Limitations
- End-to-end workflow execution not fully working
- Activity property setting needs enhancement
- Complex expression evaluation untested
Future Enhancements
Short Term
- Complete parser using Parlot for robust parsing
- Implement full control flow parsing and compilation
- Fix dynamic activity instantiation for runtime execution
- Add comprehensive error messages and diagnostics
Medium Term
- Implement flowchart parsing and compilation
- Support template strings with interpolation
- Add output capture syntax (
let result = Activity()) - Implement switch fallthrough options
- Add try/catch/finally support
Long Term
- IDE support (syntax highlighting, IntelliSense)
- Debugging support
- Performance optimizations
- Extended DSL features (custom operators, macros, etc.)
Testing Strategy
Current tests focus on:
- Parser correctness for basic constructs
- AST structure validation
- Compiler service availability
- Variable and activity node recognition
Additional testing needed for:
- Control flow execution
- Expression evaluation
- Error handling
- Edge cases and invalid syntax
Architecture Decisions
Why Regex-Based Parser?
The simplified regex-based parser was chosen to deliver a working proof-of-concept quickly. While less robust than a full Parlot implementation, it demonstrates the DSL concept and can be replaced with a more sophisticated parser later.
Why Separate AST and Compiler?
The separation allows for:
- Multiple compilation targets (if needed)
- AST analysis and transformation
- Better error reporting
- Easier testing of each component
Why Reuse Elsa's Expression System?
Rather than creating a new expression language, ElsaScript wraps Elsa's existing expression providers (JavaScript, C#, Python, Liquid). This provides:
- Consistency with existing Elsa workflows
- Proven expression evaluation
- No additional dependencies
- Familiar syntax for Elsa users
Files Added
Source Files
src/modules/Elsa.Dsl.ElsaScript/Ast/- AST node definitionsCompiler/- AST to Elsa workflow compilerContracts/- Service interfacesExtensions/- DI extension methodsFeatures/- Elsa feature moduleParser/- ElsaScript parserElsa.Dsl.ElsaScript.csproj- Project file
Test Files
test/integration/Elsa.Dsl.ElsaScript.IntegrationTests/ParserTests.cs- Parser integration testsCompilerTests.cs- Compiler integration testsElsa.Dsl.ElsaScript.IntegrationTests.csproj- Test project
Configuration
Directory.Packages.props- Added Parlot package reference
Summary
The ElsaScript DSL provides a solid foundation for text-based workflow authoring in Elsa 3. While this initial implementation has limitations, it demonstrates the core concepts and provides a framework for future enhancements. The modular architecture integrates cleanly with Elsa's existing systems and can be extended incrementally.