Test Suite for Source Maps

[romulocintra]

Based on previous meeting discussion about SM and testing, would be nice to have an analogue to WPT or test262 for this use case.

"requirements" or "potential tests"

• static linting of the physical format
• integrity check of a single sourcemap (the encoded abbreviations) against the source format (i.e do the coordinates map to token AST boundaries)
• transform checking: before/after code + sourcemap - then do integrity checking that the token/AST boundaries map

[bomsy]

i think we can reuse this for discussions and to gather info needed around conformance tests. Are there more ideas around requirements or potential tests?

[littledan]

In addition to what Romulo mentions above, the following tests seem possible to me:

• To test correctness of source map consumers, there could be tests which have as input, some compiled code, some original source, a source map, and coordinates, and as output, give the source coordinates, original source URL, and possibly a name of a function or variable (especially if we improve name mappings).
• If we define which AST boundaries should produce source map associations, we should make sure to include that in the validator/linter.
• The validator could also have a "strict mode" which checks that no extraneous elements are included (especially if we deprecate some existing unused/unimplemented features).
• As bugs often occur when composing multiple levels of compilation in a pipeline, maybe we could somehow have tests for the correctness of the operation of "composing" source maps.
• If we define how URLs are interpreted/normalized with respect to source maps, we could have tests against that logic.

[jridgewell]

rust-analyzer has an interesting approach for how to associate a lookup to a definition:
https://github.com/rust-lang/rust-analyzer/blob/cebf95718c32b1024a6845992bee96c50f830f3a/crates/ide/src/goto_definition.rs#L1669-L1698

struct Futurable;

impl core::future::IntoFuture for Futurable {
    type IntoFuture = MyFut;
}

struct MyFut;

impl core::future::Future for MyFut {
    type Output = ();

    fn poll(
     //^^^^
        self: std::pin::Pin<&mut Self>,
        cx: &mut std::task::Context<'_>
    ) -> std::task::Poll<Self::Output>
    {
        ()
    }
}

fn f() {
    Futurable.await$0;
}

Notice two points, the //^^^^ directly under poll, and the $0 in Futurable.await$0;. The $0 marks the starting location of the lookup, and the ^^^^ marks the end location.

A similar pattern could be useful for testing JS source maps. Eg a minifier could support a "keep a $0" option, would process the input code, and output minified code. The output would keep a $0 somewhere, and we could find that indentifier and perform the lookup based on that spot. The lookup should point to the ^^^^ section in the input.

[Meysamsarabadani]

this should be broken down to smaller tasks so we can get it out of the door in more like an iterative approach.

[jkup]

Just linking to @takikawa's current work on consumer testing https://github.com/takikawa/source-map-tests

[jkup]

This seems to be progressing nicely. Going to close this issue.