How is the config applied when both .swcrc present and inline config is passed?

[tomdracz]

Trying to figure this out but cannot quite make rhyme or reason of the behaviour. With example app here https://github.com/tomdracz/swc-test

.swcrc:

{
  "jsc": {
    "parser": {
      "syntax": "typescript",
      "decorators": true,
      "tsx": true
    }
  }
}

and swcOptions defined inline

const swcOptions = {
  jsc: {
    parser: {
      syntax: 'typescript',
     decorators: false,
      tsx: false,
    },
  },
};

Calling swc.transform at https://github.com/tomdracz/swc-test/blob/main/index.js#L15 processing file that has got both TSX and decorators works fine but how is the config resolution done?

For decorators and tsx properties I've noticed that:

• if both .swcrc and inline options are present, it will be processed if at least one file defines it as true
• also processed if only defined in one place as true
• not processed if missing in both places or both places set the values to false

So the behaviour suggests no way to override one config with another, right? I cannot have .swcrc defined and use programmatic config in swc.transform that changes some of the defaults. Neither does it work the other way around.

Now let's see how this works for non-booleans. Let's say I've got transformation defined as

    transform: {
      react: {
        pragma: 'fromSwcRC'
      }
    }

and

    transform: {
      react: {
        pragma: 'fromInlineConfig'
      }
    }

The generated code includes fromInlineConfig - looks like this one wins in case of duplication. If it's only defined in one place, wherever it's defined it's applied. So for (at least) some string values, I can override .swcrc with inline config. Neat! But inconsistent!

For fun what if I try and define:

{
  jsc: {
   parser: {
    syntax: 'ecmascript'
   }
  }
}

in one place or another?

It doesn't work! If syntax: ecmascript is set in .swcrc it errors out when encountering decorator. If set inline, it errors out on ts syntax. I need syntax: typescript in both places for it to work. I cannot skip setting syntax in .swcrc as I get config load error and if I skip it in my inline config, TS is not processed (falling back to ecmascript?)

So... sometimes config is seemingly overridden, sometimes it's merged, sometimes it's not. I cannot quite see a clear pattern of what works when.

Has anybody got good explanation about how is this behaviour implemented? I'm curious about inconsistencies but neither have enough Rust know-how or the knowledge of the project to know where to look. Any help would be greatly appreciated!

[kdy1]

It's merged by using Merge trait in the swc crate.
Maybe I need to remove the merging of parser config?
Basically inline configuration has higher precedence, though.

[tomdracz]

Thanks @kdy1 I did expect inline config to have higher precedence but as seen in the examples, it's not quite there.

For example setting "decorators": true in .swcrc and "decorators": false inline I would expect decorators not to be processed, by they seemingly are. Something's not quite right.

I think merging config is still quite useful. I can have my "global" settings in .swcrc and then append/override them inline if needed while still having access to everything else from the defaults. Still, this might need to operate in a more predictable way.

I'll have a peek at the swc crate and see if I can make sense of it! Thanks!

[falkenhawk]

@tomdracz is the behavior still the same like you described in the comment from January 27th?

[tomdracz]

@kdy1 Some more examples

https://github.com/tomdracz/swc-test/tree/test2

Seems like setting tsx: false inline has got no effect whatsoever. File still gets processed fine. This is seemingly only working when set in .swcrc

Also, does using jsx/tsx implies:

    transform: {
      react: {
        runtime: 'classic'
      }
    }

That's what the output is matching up. Bit confused as defaults at https://swc.rs/docs/configuration/compilation suggest transform: null is the default here.

Should I open up issue for this one?

[kdy1]

tsx can be an issue, but transform one is an issue of documentation.