asl-validator v3.0.0 roadmap

[ChristopheBougere]

Here is the roadmap for the next major release:

• Switch to another JSON path library to solve asl-validator not working on the browser #77 and validator rejects path expression containing a hyphen #81
• Rewrite to typescript (started here)
• Setup semantic release on github actions (started here)
• Add flags to disable some checks (see discussion here)
• Improve readme with details about the new checks
• Add contributors to the readme (started here)
• Implement asl-path-validator

[ChristopheBougere]

@massfords with all the changes I think we can target a new major version
I've started on a branch a rewrite to TypeScript and to automate the release workflow
Feel free to share your thoughts!

About your comment here, what would be the pros of a level system vs the ability to enable/disable each check?
IMO, by default users would like to validate everything. But if they face an issue (due to a bug in asl-validator, or in a 3rd party library like JSON path), they would like to disable this specific check.

[massfords]

Named checks feels more like a linter than a compiler. I can see having named checks more if we start adding rules for style issues or probable bugs.

We should not allow users to disable some of the basic structural rules (Level 1 and 2 from my example). Apart from having to workaround a bug, I don't see a good reason to disable a rule like schema validation or duplicate state names.

I'm less concerned about the path expressions being validated since it's a fair amount of work to get it right and I'd rather see it working for real in the AWS emulator or live system. The closer I get to deploying a state machine, the less important the validation is since the emulator or live service will do the validation for me.

One thing I recall from the AWS step function editor is that I couldn't paste my ASL source code into the editor and get a good error message. The problem is that my ASL source had substitution variables for the Task.Resource values. These were set during deployment to fully qualified ARN values to their target lambda or similar.

asl-validator 2.x doesn't yet check the Task.Resource shape to see if it's a well formed ARN. When asl-validator 3.x includes this validation, I would likely disable that specific rule or not run to that level.

[ChristopheBougere]

thanks for your explanation, that makes sense to me

[massfords]

I'm less concerned about the path expressions being validated since it's a fair amount of work to get it right and I'd rather see it working for real in the AWS emulator or live system.

Update on my comment above: It actually wasn't that much work but it was enough to warrant a separate project. See the asl-path-validator project.

I like the approach of having named validators but basic schema validation should be run at a minimum. I typically have multiple iterations of the process during the design phase so I defer the mappings work until I'm sure what the steps are.

Development Stage	Basic Structure schema valid	Basic Semantics valid graph	Expressions asl-path-validator	Task Addressing valid ARN
Design	✅	✅
Test	✅	✅	✅
Deploy	✅	✅	✅	✅

If there are named rules, then I could disable them by name based on the development stage I was in.

[ChristopheBougere]

I've published a first version of the 3.x version.
3.0.0 had a bundling issue, but 3.0.1 should work and include all the latest changes.
Now, merging a PR on main should automatically trigger a release (if the commit messages are correct).