Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Respect tsconfig.json and/or .babelrc #1348

Closed
hassankhan opened this issue Jan 22, 2021 · 11 comments
Closed

Respect tsconfig.json and/or .babelrc #1348

hassankhan opened this issue Jan 22, 2021 · 11 comments

Comments

@hassankhan
Copy link

hassankhan commented Jan 22, 2021

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
Copy link

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

@kdy1
Copy link
Member

kdy1 commented Mar 10, 2021

@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
Copy link

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
Copy link
Member

kdy1 commented Apr 19, 2021

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
Copy link
Contributor

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

This comment has been minimized.

@CMCDragonkai

This comment has been minimized.

@kwonoj
Copy link
Member

kwonoj commented Jul 25, 2022

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

This comment was marked as spam.

@kwonoj
Copy link
Member

kwonoj commented Jul 24, 2023

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.

@kwonoj kwonoj closed this as completed Jul 24, 2023
@swc-bot
Copy link
Collaborator

swc-bot commented Aug 24, 2023

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.

@swc-project swc-project locked as resolved and limited conversation to collaborators Aug 24, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

9 participants