Input Source Map in Test Fixture, Loading Source Maps

[stahlbauer]

I am currently developing a (will be open source) SWC plugin. I would like to perform some of the tests with input source maps, loaded from source maps that are separated from the transpiled source files (no inline comments with source maps).

What is the best way to load a foo.js.map file into a SourceMap object? Are there already best practices in context of writing tests for plugins?

[kdy1]

@kwonoj I think we should provide an API in swc_ecma_transforms_testing for testing source maps.
Thoughts? I can implement one quickly, but I want to hear opinions before starting to work on it.

I'm considering add an option to test_fixture.

[kwonoj]

Having a new testing utility doesn't seem to harm since it isn't public interface for the core. 👍

[kdy1]

Implemented via #6079 and it will be automatically published once merged.

You can pass FixtureTestConfig { sorucemap: true, ..Default::default() } to test_fixture.
It will print a url to sourcemap visualizer on failure.

[stahlbauer]

Thanks for this fast reaction.

Given the following situation: I have a directory tests/fixtures/test1 that includes the files input.js, input.js.map, and output.js. The plugin is supposed to use both input.js and input.js.map to perform is transformations, resulting in a new output.js to compare along with a new inline or external source map.

(How) can I use the new feature to

1. load the source map input.js.map as part of the test fixture and use it to test a transformer. A transformer function transform takes a Arc<SourceMap> as argument. This source map is provided by SWC in the TransformPluginProgramMetadata in the attribute metadata.source_map behind a proxy of type PluginSourceMapProxy (please correct me if I am wrong here).
2. load the produced source map from the transformation output to check it for expected attributes.

[kdy1]

You can just use the correct span.
For example, if

consolel.log(a)

is transformed to

consolel.log({ a: 'a' })

by transform (a => { a: 'a'}), you can simply return correct span.
You only need to verify that the span of a is used for relevant nodes.

After then, @swc/core will generate a source map, and remap to the original source code if the user specifies the input source map.

If you want to unit test including the input source map, the easiest way would be to create a custom test using @swc/core and @swc/jest, but I wouldn't do that, and I don't recommend it

[stahlbauer]

What I understand is that SWC takes care of doing the source mapping and produces a corresponding source map.

Some more background on what I am trying to do: I would like to do additional transformation based on the source map information in my pass. For example, if the code to transform stems from some node_module, I would like to treat it different from code that is directly from the applications src folder. So I have to be able to get the sourcemap in my tests from somewhere.

[stahlbauer]

Currently, I am using span_to_snippet for that purpose.

And now I am trying to test this feature by providing source maps from the fixture. Before doing thisspan_to_snippet lookup, a sequence of other SWC plugins is applied to do some upfront transformations. Here, I have to assume that the source map information is preserved (which should be a valid assumption, as discussed previously).

[stahlbauer]

A problem I face currently, is that the call to span_to_snippet and with this to lookup_char_pos and to lookup_source_file panics in case the location cannot be resolved. I would love if these lookup function could provide an Option as return type.

[kdy1]

Check for DUMMY_SP

[stahlbauer]

Or the invariant that each AST node must always be map-able to some location must be ensured.

[stahlbauer]

I will trying to check for DUMMY_SP for now.