Add portable JSON compatibility fixtures - #13
Open
callumalpass wants to merge 2 commits into
Open
callumalpass wants to merge 2 commits into
callumalpass wants to merge 2 commits into
Conversation
|
I'd be excited to see knap-mdbase synthesis! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hi @kepano.
Knap looks like a great project, and I'd be keen to use it as the templating system for a project that I'm currently working on, mdbase.
To use it there, I'd need a Rust implementation of Knap. I'd be keen to build and maintain one, and this PR is intended as a step towards making Knap's expectations easier to share among implementations and across languages.
This PR exports expectations from the Knap documentation and regression tests as JSON fixtures that can be reused in other implementations. The TypeScript tests also run against those fixtures, so all implementations would check themselves against the same expectations.
This PR should be understood to be a proposal for a test corpus rather than a complete specification. It captures existing expectations, but leaves some edge cases untested. I believe there are edge cases around type coercion, Unicode, regular expressions, dates and time zones, and serialization. Those areas may need additional test cases to establish expectations that implementations in different languages could reliably share. On the other hand, some of these edge cases might be sufficiently rare that leaving them unspecified would make implementations easier to build and maintain!