Respect tsconfig.json and/or .babelrc

[hassankhan]

It would be awesome if swc could read settings from existing tsconfig.json and/or .babelrc in a project. This would be super useful since there seems to already be some overlap, and would save new users a trip to the documentation to figure out what swc's options are.

[tbillington]

Second this, would make adoption incredibly simple, just swap out our tsc -b tsconfig.json with swc tsconfig.json 🎉

[kdy1]

@tbillington I know it worth, but I don't have time. I will happy to accept pr.

And please use +1 feature of github instead of spamming watchers.

[drivasperez]

I've had a look at parsing tsconfigs into Rust, and this is a nice motivator to do it; it's slightly complicated because one tsconfig can extend others (ie, you might have tsconfig.dev.json, tsconfig.prod.json, both inheriting from a tsconfig.base.json), and certain settings imply others (setting some flag to true means that some other flag defaults to false if unset, where it would otherwise default to true). A couple of questions:

• Which tsconfig settings correspond to which .swcrc settings? Presumably things like bundle type should only correspond to typescript files? E.g., as in: https://swc.rs/docs/configuring-swc#multiple-entries
• Should the parsing code for the tsconfig live in swc, or should swc add a dependency to a new crate?

[kdy1]

Which tsconfig settings correspond to which .swcrc settings? Presumably things like bundle type should only correspond to typescript files? E.g., as in: https://swc.rs/docs/configuring-swc#multiple-entries

I think tsconfig can be used to all files if .swcrc does not exist. If .swcrc exists, it should get higher precedence over tsconfig.json, regardless of language.

As I expect to a user to use only typescript and javascript in single project, I think applying to all language is correct way to go.

Should the parsing code for the tsconfig live in swc, or should swc add a dependency to a new crate?

Both is acceptable, if tsconfig to swc-config lives in swc repository.

[songkeys]

I'm also looking for this but can't find any. So I just wrote a config-mapping node module tsconfig-to-swcconfig which maps configs in tsconfig.json to configs in .swcrc. (Only a subgroup of features of tsconfig is supported by swc currently, however.)

I also wrote some other libraries based on this:

• tswc which allows you to use tswc -- [swc options] to compile with tsconfig respected.
• swc-register which allows you to use node -r swc-register file.ts to transpile TypeScript files on the fly, also, with tsconfig.json respected.

[CMCDragonkai]

When we use @swc/jest does it recognise the settings in tsconfig.json? Or do we need to map tsconfig.json to .swcrc first?

I ask because I've started to use swc as part of ts-node and the author of ts-node said no additional configuration is required, as tsconfig.json is still respected. But now I'm wondering if that applies across the board to include jest as well...?

[CMCDragonkai]

And if it isn't possible I reckon it would be nice to document this explicitly for each of the tools.

[kwonoj]

SWC does not interop tsconfig.json or babelrc or any other configs as of today. There were internal discussions, while techinically nothing prevents it we do not have any immediate plan to introduce it in @swc/core - probably any userland support would come first.

[eklenin]

Really important feature, I think, cause seems like eslint currently works only with .tsconfig files - https://github.com/swc-project/swc/issues/246

In that way, it multiplies config files required, one for linting and other for building. Most modern projects already have a lot of boilerplate in their initial commits, I do not think adding another one makes people's lifes better :smiling_face_with_tear:

[kwonoj]

I'm going to close this for now, implcit interop between configuration can help some and as well as confusing other usecase pretty quickly. At least, if we are really going to do this it needs very careful design to understand what's going on. Core team will internally put this into backlog to determine if we really wants this or not, however for now we don't have strong desire to have this.

[swc-bot]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.