Implement swcx `compile` to feature parity to @swc/cli

[kwonoj]

Describe the feature

Related with https://github.com/swc-project/swc/discussions/3859.

We want to establish initial feature parity to existing @swc/cli to plan out migration with possible breaking changes.

These are initial flags we'd like to have.

• [ ] config
• [x] config_file
• [x] filename (https://github.com/swc-project/swc/pull/4016)
• [x] env_name
• [x] ignore
• [x] source_maps (https://github.com/swc-project/cli/blob/d60fa69498e970ec045b194bf13a31c9ed6ce413/src/swc/file.ts#L78)
• [x] source_maps_target
• [x] source_file_name (https://github.com/swc-project/swc/pull/6973)
• [x] source_root (https://github.com/swc-project/swc/pull/6973)
• [ ] watch
• [x] out_file (https://github.com/swc-project/swc/pull/4016)
• [x] out_dir
• [x] extensions
• [x] files
• [x] experimental_trace
• [x] trace_out_file

Babel plugin or link to the feature description

No response

Additional context

No response

[RiESAEX]

just found filename is Implemented in #4016

[Bruce-Hopkins]

I'm looking to contribute to this project, but it seems all the flags here have already been implemented according to the docs.

[kwonoj]

It is not, please see above list with checkboxes.

[Bruce-Hopkins]

It is not, please see above list with checkboxes.

Oh, I'm sorry, I got confused with the JS cli tool. I will open a PR hopefully soon to add one of these.

[realtimetodie]

• [x] source_maps
• [x] source_maps_target

were resolved in https://github.com/swc-project/swc/pull/6708

[realtimetodie]

I'm working on the implementation of the --config option.

[alexeagle]

Another TODO item: document the CLI options on the docsite somewhere. Right now tools like Bazel have to recommend that users run swcx --help to see how to use it.

[Aghassi]

+1 on the documentation. I see the --config option was implemented, but when I run it I get an error with the old syntax

❯ ~/Downloads/swc-darwin-arm64 compile --config=jsc.transform.react.importSource=@emotion/core
error: Invalid value "jsc.transform" for '--config <CONFIG>': expected value at line 1 column 1

@realtimetodie Would you be able to explain the changes here? I see this just came out in 1.3.34 so no worries, I know it's fairly new.

[realtimetodie]

https://github.com/swc-project/swc/pull/6835

[alexeagle]

We document that in a user example now too: https://github.com/aspect-build/rules_swc/commit/8db4ee5e5e26ba6dce331fca9164dbcfcdc1e1ff

[Aghassi]

Thanks @alexeagle and @realtimetodie . So it looks like the --config now takes a json object instead of a dot notation object when switching between the node and rust based cli(s)

[alexeagle]

FWIW I suspect that's not intentional. @titanous when you added the --config support, did you mean for the syntax to be different from @swc/cli ?

[kdy1]

Should we revert it for now? Maybe it should be another name... cc @kwonoj

[titanous]

Ah, I didn't know that it was already implemented in @swc/cli. Maybe we should rename to --config-json? I don't really feel like implementing a custom parser for whatever syntax was previously used.

[kdy1]

I think so, we should rename it

[titanous]

Renamed in #6932.

[Klaitos]

Hello, is adding the --copy-files flag planned aswell ?

[realtimetodie]

• [x] source_file_name
• [x] source_root

were resolved in https://github.com/swc-project/swc/pull/6973

[hopefullToo]

I work on an Apple M1 machine. arch: arm64. The problem described occurs regardless of whether swc_cli is also available as a binary installed by cargo.

As described here [(https://swc.rs/docs/getting-started)]() I installed @swc/cli and @swc/core.

Then when I call npx swc --help it shows the help, When I call npx swcx --help I get this error message:

Error: No binary found matching your system. It's probably not supported. at BinWrapper.download (/....../_swccli/node_modules/@mole-inc/bin-wrapper/index.cjs:33675:10) at BinWrapper.findExisting (/....../_swccli/node_modules/@mole-inc/bin-wrapper/index.cjs:33658:17) at async BinWrapper.run (/........./_swccli/node_modules/@mole-inc/bin-wrapper/index.cjs:33619:3) at async executeBinary (/......../_swccli/node_modules/@swc/cli/lib/swcx/index.js:145:5)

swcx is available at node_modules/.bin/.

The swc.darwin-arm64.node file is located in the node_modules/@swc/core-darwin-arm64/ directory. I tentatively made swc.darwin-arm64.node executable with chmod 755. But I can't run it stand alone. This error message appears: zsh: exec format error: ./swc.darwin-arm64.node

[hopefullToo]

Should I open a new issue?

[Klaitos]

There is a difference in output directory structure when using swcx cli vs classic swc.

npx swcx compile src --out-dir dist will generate :

➜  swc tree dist     
dist
└── src
    └── index.js

npx swc src --out-dir dist will generate :

➜  swc tree dist                  
dist
└── index.js

1 directory, 1 file

The src folder is kept in new version of the cli.

Is that a expected behavior ? It gives me some issues when uploading source-map to Sentry because I have to manipulate some path

Thanks !

[giraffesyo]

Was trying this out but two issues (already mentioned) are blockers for using the new version:

• No --copy-files, use case is .json files and other arbitrary files inside the source tree that are required by the application. (mentioned https://github.com/swc-project/swc/issues/4017#issuecomment-1432029843)
• Output directory changes to include top level directory in output structure. i.e. src folder is included. I doubt this is intentional? (mentioned https://github.com/swc-project/swc/issues/4017#issuecomment-1506730719)

[theoludwig]

@Klaitos @giraffesyo

Output directory changes to include top level directory in output structure. i.e. src folder is included. I doubt this is intentional?

The workaround for this, is to use the --strip-leading-paths CLI flag. Build command could be the following: swc ./src --out-dir ./build --strip-leading-paths --delete-dir-on-start.

[jwalton]

The workaround for this, is to use the --strip-leading-paths CLI flag.

Is there a way to specify this in the config file?

[jfhbrook]

I can +1 the arm mac issue. This is on 0.4.1-nightly.30340914.