interop test files

[bnewbold]

Add a top-level directory to this repo containing interop test files ("test vectors", "test fixtures"). And then start using those files directly from syntax and crypto packages.

The main point here is to have the files in a format which is easy for cross-language parsing and reuse (eg, by directly copying the files). I pulled these specific files from recent golang work, where I had manually copied values out of the typescript tests.

I'm not sure if symlinking is the best way to go here. Could also symlink in the other direction, or just copy the files, etc. It would be good to ensure (in an automated way) that the files are exactly what is getting tested in this repo.

There are additional interop tests for MST structure, MST implementation details (prefix lengths), and Lexicons, which could be reformatted for this directory. I imagine we'll also have a bunch of binary CBOR and CAR files which would go well here. I think we might also be able to include HURL files for basic HTTP API testing (https://hurl.dev/).

[estrattonbailey]

Love this idea!

Idk why symlinks wouldn't work necessarily, seems fine to me, but another option could be to use TS/Babel path aliases. Since this is all run within Jest, these wouldn't apply to runtime code and should be fine. That would look something like:

1. add paths to tsconfig, module-resolver to babel, etc
2. specify, say, #interop/* as an alias for ../../interop-test-files/*
3. import those files into tests like require('#interop/nsid_syntax_invalid.jsonc')

[estrattonbailey]

Idea: we could use JSON5 for JSON+commenting and just require the files here 🤔 could reduce boilerplate maybe. Would require some Jest/Babel plugins but looks like there are options

[bnewbold]

I've had good experiences with TOML, which has good commenting. An advantage of any wrapped format is that any weird bytes are obvious because of quote encoding.

The downside is that we want whatever we used to be as easy to parse and use in any implementation language, which is why I stuck to text and JSON so far. I think having it be the exact same file on disk across projects is a big advantage. But maybe TOML/JSON5 isn't a heavy lift in most languages these days.

[estrattonbailey]

Oh yeah TOML could work too. Good call that if you want them portable we need to consider the universality of the format 👍

[bnewbold]

Oh interesting, nice feature of TS/babel.

The concern with symlinks would be that, eg, exporting the individual packages (eg, upload to npm), then trying to run the tests from the exported version, would fail, depending on whether the symlink is "resolved" when creating an archive/bundle or not.

This is probably overthinking things and we can just stick with symlinks unless/until they cause an actual problem.

[estrattonbailey]

then trying to run the tests from the exported version

I don't think this is a super common use case, but I could be wrong. A lot of npm packages actually strip out most files except those required by the library to reduce download size. Or maybe I'm misunderstanding you, but as long as symlinks aren't used in the compiled/bundled javascript then we should be fine.

[bnewbold]

I think it is good to merge then.

The package tests might be an ecosystem-specific thing. In Python and Rust it is not uncommon to download a package and expect to be able to run the tests. In Rust it is also common for third parties to download the entire package repo and run the tests over every single package to test, eg, compiler changes, or language syntax updates.

[estrattonbailey]

Love it, thanks for compiling all this!

[dholms]

yup looks good 👍

agreed we can adjust this structure over time but this works well for now

merged in main (with our new package management) & will get this merged here shortly