aspect-build / rules_swc Goto Github PK

This is a super minor one, but this script will fail if the user doesn't have gsed installed. Consider adding a check and failing fast with install instructions.

What happened?

https://github.com/aspect-build/rules_swc/blob/main/.github/workflows/ci.yaml#L36 should include a windows runner.

Some of the sourcemap handling has argv quoting bugs

Version

WINDOWS :/

How to reproduce

No response

Any other information?

No response

Fund our work

• Sponsor our open source work by donating a bug bounty

What is the current behavior?

• add an e2e/bzlmod (or make all e2e/examples run in dual mode)
• add the MODULE.bazel snippet to releases
• add auto-publishing to the bazel-central-registry on releases
• update our blog post and example repo https://blog.aspect.dev/bzlmod

Describe the feature

Bazel 6 is out so users expect this.
Will be required for rules_ts 2.0 to default to swc for transpilation

Fund our work

• Sponsor our open source work by donating a feature bounty

What happened?

rules_swc is great, but I think the performance of this ruleset could be improved by some tweaks to the action graph it creates. Presently, one action is created per file, which creates immense overhead. Doing a cold build of a large codebase takes 30+ mins when SWC unencumbered could probably eat through it in less than a minute. This appears to be Bazel overhead from spawning so many actions, and them consequently being queued up. For (a) performance and (b) because it didn't appear to add much value, I disabled sandboxing in .bazelrc for SWCTranspile, but needless to say, sandboxing on top is going to further inflate the time taken. I imagine one-action-per-file is also costly from a remote cache / RBE perspective.

After a cold build, incremental build time is superb, but I think it would be just as fast with, say, 5-10 files per action as 1. Perhaps an int attr could be added that specifies how many files will be inputs to each action, with a default that is greater than 1 but not too large either, to enable some economy of scale..

Version

~

How to reproduce

No response

Any other information?

No response

Fund our work

• Sponsor our open source work by donating a bug bounty

What happened?

Supposing something like the following:

load("@aspect_rules_ts//ts:defs.bzl", "ts_project")
load("@aspect_rules_swc//swc:defs.bzl", "swc")
load("@bazel_skylib//lib:partial.bzl", "partial")

ts_project(
    name = "foo",
    srcs = ["foo.mts"],
    transpiler = swc,
    tsconfig = "//:tsconfig",
)

We ought to expect an .mjs file on the output side, very much in line with nodenext and what tsc alone does. However, it seems that swc doesn't currently support .mts/.cts -> .mjs/.cjs conversion, so while the build task runs there are no outputs or errors from ts_project.

Version

Development (host) and target OS/architectures:

Output of bazel --version: bazel 6.0.0

Version of the Aspect rules, or other relevant rules from your
WORKSPACE or MODULE.bazel file: rules_ts-1.0.4 & rules_swc-0.20.0

Language(s) and/or frameworks involved: TS & swc

How to reproduce

See above :)

Any other information?

No response

Fund our work

• Sponsor our open source work by donating a bug bounty

Issue description in commit message here: mdittmer/bazel-sandbox@03b685b (commit contains code to reproduce issue).

This issue was observed running bazel on mac with rules_swc-0.5.1.

Description copied here for convenience:

swc() rule that compiles transitive dependencies succeeds on first build, but fails on second build while copying files.

$ cd js && npm install && bazel clean --expunge && bazel build //:swc && bazel build //:swc
npm WARN [email protected] No description
npm WARN [email protected] No repository field.

added 14 packages from 66 contributors and audited 14 packages in 1.092s
found 0 vulnerabilities

INFO: Starting clean.
Starting local Bazel server and connecting to it...
INFO: Analyzed target //:swc (68 packages loaded, 403 targets configured).
INFO: Found 1 target...
Target //:swc up-to-date:
  bazel-bin/node_modules/aws-sdk/scripts/services-table-generator.js
INFO: Elapsed time: 10.869s, Critical Path: 0.83s
INFO: 60 processes: 33 internal, 1 darwin-sandbox, 26 local.
INFO: Build completed successfully, 60 total actions
INFO: Analyzed target //:swc (1 packages loaded, 25 targets configured).
INFO: Found 1 target...
ERROR: /path/to/bazel-sandbox/js/BUILD.bazel:3:4: Copying file bazel-bin/node_modules/aws-sdk/scripts/services-table-generator.ts failed: (Exit 1): bash failed: error executing command /bin/bash -c 'cp -f "$1" "$2"' '' bazel-bin/node_modules/aws-sdk/scripts/services-table-generator.ts bazel-out/darwin-fastbuild/bin/bazel-bin/node_modules/aws-sdk/scripts/services-table-generator.ts
cp: bazel-bin/node_modules/aws-sdk/scripts/services-table-generator.ts: No such file or directory
Target //:swc failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 0.758s, Critical Path: 0.27s
INFO: 8 processes: 6 internal, 2 local.
FAILED: Build did NOT complete successfully

See bazelbuild/rules_nodejs#3311

What happened?

ERROR: /platformweb/ui/dashboard/src/components/TitleBar/BUILD.bazel:3:15: in swc_transpiler rule //platformweb/ui/dashboard/src/components/TitleBar:TitleBar_transpile: 
Traceback (most recent call last):
        File "/shared/cache/bazel/user_base/35d3dfb99a7e1d1ac0ae38df0bff0ffd/external/aspect_rules_swc/swc/private/swc.bzl", line 160, column 46, in _impl
                inputs = [copy_file_to_bin_action(ctx, src)] + swcinfo.tool_files
        File "/shared/cache/bazel/user_base/35d3dfb99a7e1d1ac0ae38df0bff0ffd/external/aspect_bazel_lib/lib/private/copy_to_bin.bzl", line 84, column 21, in copy_file_to_bin_action
                copy_file_action(ctx, file, dst)
        File "/shared/cache/bazel/user_base/35d3dfb99a7e1d1ac0ae38df0bff0ffd/external/aspect_bazel_lib/lib/private/copy_file.bzl", line 84, column 31, in copy_file_action
                coreutils = ctx.toolchains[_COREUTILS_TOOLCHAIN].coreutils_info
Error: In swc_transpiler rule //platformweb/ui/dashboard/src/components/TitleBar:TitleBar_transpile, toolchain type @aspect_bazel_lib//lib:coreutils_toolchain_type was requested but only types [@aspect_rules_swc//swc:toolchain_type] are configured

Same idea as aspect-build/rules_webpack#135

Version

HEAD

How to reproduce

No response

Any other information?

No response

What happened?

When we changed to swcx we changed the sourcemaps:

https://github.com/aspect-build/rules_swc/blob/main/examples/rc/src/expected.js.map
"sources":["examples/rc/src/in.ts"]
https://github.com/aspect-build/rules_swc/blob/v0.20.1/examples/rc/src/expected.js.map
"sources":["in.ts"]

Version

It changed in the commit where we switched from @swc/cli (the nodejs wrapper) to swcx
https://github.com/aspect-build/rules_swc/commit/6358e06ac2a8d6aca2c2ea0cd6ea9dc7b9217a27#diff-90f27955a28ad20f91303a[…]4c55c9ef8b0ccb3255a1bdd1f726

What happened?

I'm using something simple like this in order to produce source_maps:

This file is in a BUILD.bazel in a folder hello

ts_project(
    name = "lib",
    srcs = glob([
        "src/**/*.ts",
    ]),
    declaration = True,
    declaration_map = True,
    source_map = True,
    transpiler = partial.make(
        swc,
        source_maps = True,
        swcrc = ":.swcrc",
    ),
    tsconfig = "tsconfig",
    validate = True,
    visibility = ["//visibility:public"],
    deps = [
        ":node_modules",
    ],
)

It produce:

{
   "version":3,
   "sources":[
      "index.ts"
   ],
   ...
}

Where it should be:

{
   "version":3,
   "sources":[
      "src/index.ts"
   ],
   "sourceRoot":  "hello"
   ...
}

Version

Development (host) and target OS/architectures:

Output of bazel --version:
6.4.0

Version of the Aspect rules, or other relevant rules from your
WORKSPACE or MODULE.bazel file:

http_archive(
    name = "rules_nodejs",
    sha256 = "162f4adfd719ba42b8a6f16030a20f434dc110c65dc608660ef7b3411c9873f9",
    strip_prefix = "rules_nodejs-6.0.2",
    url = "https://github.com/bazelbuild/rules_nodejs/releases/download/v6.0.2/rules_nodejs-v6.0.2.tar.gz",
)

http_archive(
    name = "aspect_rules_swc",
    sha256 = "8eb9e42ed166f20cacedfdb22d8d5b31156352eac190fc3347db55603745a2d8",
    strip_prefix = "rules_swc-1.1.0",
    url = "https://github.com/aspect-build/rules_swc/releases/download/v1.1.0/rules_swc-v1.1.0.tar.gz",
)

http_archive(
    name = "aspect_rules_ts",
    sha256 = "bd3e7b17e677d2b8ba1bac3862f0f238ab16edb3e43fb0f0b9308649ea58a2ad",
    strip_prefix = "rules_ts-2.1.0",
    url = "https://github.com/aspect-build/rules_ts/releases/download/v2.1.0/rules_ts-v2.1.0.tar.gz",
)

http_archive(
    name = "aspect_rules_js",
    sha256 = "76a04ef2120ee00231d85d1ff012ede23963733339ad8db81f590791a031f643",
    strip_prefix = "rules_js-1.34.1",
    url = "https://github.com/aspect-build/rules_js/releases/download/v1.34.1/rules_js-v1.34.1.tar.gz",
)

Language(s) and/or frameworks involved:

How to reproduce

No response

Any other information?

No response

What happened?

https://buildkite.com/bazel/bcr-presubmit/builds/839
is stuck at

(18:38:04) [5 / 7] Compiling //:compile [swc foo.ts]; 4216s local, remote-cache

Running the swc.exe command line manually on windows 10 seems to work fine. My windows machine isn't able to run Bazel 6 due to some dll problem.

Version

HEAD

What happened?

While running the latest version of SWC rules, it crashes with this error:

ERROR: /Users/romain/git/oidc/packages/i18n/express/BUILD:25:11: Compiling //packages/i18n/express:ts_transpile [swc packages/i18n/express/src/i18n.ts] failed: (Exit 101): swc-darwin-arm64 failed: error executing command (from target //packages/i18n/express:ts_transpile) 
  (cd /private/var/tmp/_bazel_romain/aab898f10bfeb90def8d69f3c9616e24/sandbox/darwin-sandbox/1652/execroot/com_shadow_cbp && \
  exec env - \
  external/swc_darwin-arm64/swc-darwin-arm64 compile --source-maps true --source-file-name ../src/i18n.ts --source-root packages/i18n/express --config-file bazel-out/darwin_arm64-fastbuild/bin/packages/i18n/express/.swcrc --out-file bazel-out/darwin_arm64-fastbuild/bin/packages/i18n/express/src/i18n.js packages/i18n/express/src/i18n.ts)
# Configuration: 7f308466bd98cfb2b391af4037586009214979163f843b0f91a1705af46bb64c
# Execution platform: @local_config_platform//:host

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
thread 'main' panicked at 'base_dir(``) must be absolute. Please ensure that `jsc.baseUrl` is specified correctly. This cannot be deduced by SWC itself because SWC is a transpiler and it does not try to resolve project details. In other works, SWC does not know which directory should be used as a base directory. It can be deduced if `.swcrc` is used, but if not, there are many candidates. e.g. the directory containing `package.json`, or the current working directory. Because of that, the caller (typically the developer of the JavaScript package) should specify it. If you see this error, please report an issue to the package author.', /Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/swc_ecma_transforms_module-0.173.38/src/path.rs:104:13

Version

Development (host) and target OS/architectures:

Output of bazel --version:
bazel 7.1.1

Version of the Aspect rules, or other relevant rules from your
WORKSPACE or MODULE.bazel file:
rules_swc-1.2.2
rules_ts-2.2.0
rules_js-1.40.0

Language(s) and/or frameworks involved:
TS

How to reproduce

No response

Any other information?

While upgrading from rules_swc-1.1.0 to rules_swc-1.2.2

I am trying to add path aliases through .swcrc by specifying paths

Here is my .swcrc

{
  "jsc": {
    "parser": {
      "syntax": "typescript"
    },
    "target": "es2021",
    "baseUrl": ".",
    "paths": {
      "@connectors/*": ["./src/connectors/*"],
      "@operations/*": ["./src/operations/*"]
    }
  },
  "module": {
    "type": "commonjs"
  }
}

When paths are specified and I attempt to use the path-alias for an import, the build is successful but I get the following runtime error

 Error: Cannot find module '../../../../../../../../../../.cache/bazel/_bazel_victor/b76e982e01c6243367a3fb2de72a73de/execroot/[redacted]/bazel-out/k8-fastbuild/bin/backend/packages/grpc-error/index'

grpc-error is one of our other packages built with the bazel js-library rule.

It seems like "paths" is actually working, because it allows me to use the path-aliases, the build doesn't crash. However the resulting import path isn't valid, the file doesn't exist, and I am guessing there is some bazel magic I don't understand going on in the background. The resulting import path when paths is not specified and I don't attempt to use the path-alias looks like this @[package-name]/grpc-error, which is the name of the library.

To summarize

//.swcrc
{
...
    "paths": {
      "@connectors/*": ["./src/connectors/*"],
      "@operations/*": ["./src/operations/*"]
    }
...
}

results in

var _grpcError = require("../../../../../../../../../../.cache/bazel/_bazel_victor/b76e982e01c6243367a3fb2de72a73de/execroot/energy_services/bazel-out/k8-fastbuild/bin/backend/packages/grpc-error/index");

and a run-time error

and

// .swcrc
{
...
    // "paths": {
    // "@connectors/*": ["./src/connectors/*"],
    // "@operations/*": ["./src/operations/*"]
    // }
...
}

results in

var _grpcError = require("@ingka/grpc-error");

I am trying to migrate a large code base to using swc transpiler and I keep getting

FATAL: bazel ran out of memory and crashed. Printing stack trace:
java.lang.OutOfMemoryError: Java heap space

The only difference I see in my config is the use of --enable_runfiles . I have looked into the code to
understand why this flag is needed and if it is possible to turn it off.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Repository problems

These problems occurred while renovating this repository.

• WARN: Error updating branch: update failure

Errored

These updates encountered an error and will be retried. Click on a checkbox below to force a retry now.

• chore(deps): update dependency bazel_skylib to v1.3.0

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update dependency io_bazel_stardoc to v0.5.3
• chore(deps): update dependency aspect_rules_js to v1.4.0
• chore(deps): update dependency rules_nodejs to v5.6.0
• Click on this checkbox to rebase all open PRs at once

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• chore(deps): update dependency bazel_gazelle to v0.27.0
• chore(deps): update dependency io_bazel_rules_go to v0.35.0

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

It's slow to start a NodeJS process for every spawn of swc, and it's extra weight to send to remote execution service.

SWC has a binary codenamed "swcx" which is the bare Rust binary without the node binding. This should be suitable for use in Bazel.

#57 has some longstanding WIP for this, but it needs a sponsor to fund the rest of the work.

Now that swc-project/swc#4057 has been closed, if the SWC binary being used by rules_swc is updated to v1.2.218, it should be possible to remove the flag that disables the sandbox:

Building typescript srcs using ts_project rule with swc transpiler fails in RBE mode since swc version 0.5.1 (also tested with the latest release v0.7.0). Local sandbox execution is successfull.

Prior to v0.5.0, swc RBE transpilation worked just fine with the same config.

The output stack trace of the error is:

Error: Cannot find module 'slash'
Require stack:
- /var/lib/../exec/bazel-out/exec/bin/external/aspect_rules_swc/swc/node_modules/@swc/cli/lib/swc/dir.js

It looks like in RBE mode executors cannot resolve npm dependencies required by swc cli.
I've checked that slash package can be found in /var/lib/../exec/bazel-out/exec-EAxs2/bin/external/aspect_rules_swc/swc/node_modules/.aspect_rules_js.

Repro

I've created a test case repository to show all the config that makes it fail.

https://github.com/danigar/bazel-swc-lab

What is the current behavior?

Followup to #149 which introduces plugin support but only documents how to use them for pre-built plugins distributed as wasm files.

Describe the feature

#149 (comment) suggests that users ought to be able to use rules_rust to have their plugin code live in the monorepo alongside the swc_plugin rule.

/cc @realtimetodie @titanous

Fund our work

• Sponsor our open source work by donating a feature bounty

What is the current behavior?

Currently SWC has an "allowed versions" list. This means if we specify a version not in https://github.com/aspect-build/rules_swc/blob/v0.19.3/swc/private/versions.bzl, we fail. This can be confusing to end users who may need to keep SWC version mirrored with a package.json.

Describe the feature

It would be nice if this mirrored the functionality that rules_ts has that let's you specify a version from a target package.json. this way, when a project updates SWC, this gets that version and doesn't lockdown the allowed versions.

Fund our work

• Sponsor our open source work by donating a feature bounty

What happened?

An import that utilizes swc paths (examples/paths/src/modules/moduleA/index.js) is generated with a much longer relative path than should be needed.

Actual:

"use strict";
Object.defineProperty(exports, "__esModule", {
    value: true
});
Object.defineProperty(exports, "moduleA", {
    enumerable: true,
    get: ()=>moduleA
});
const _moduleB = require("../../../../../../../.cache/bazel/_bazel_jacob/0c86d75ab0e68ba3b8d2283871991c92/sandbox/linux-sandbox/66/execroot/aspect_rules_swc/src/modules/moduleB");
const moduleA = ()=>{
    console.log("This is module A");
    (0, _moduleB.moduleB)();
};

Expected:

"use strict";
Object.defineProperty(exports, "__esModule", {
    value: true
});
Object.defineProperty(exports, "moduleA", {
    enumerable: true,
    get: ()=>moduleA
});
const _moduleB = require("../moduleB");
const moduleA = ()=>{
    console.log("This is module A");
    (0, _moduleB.moduleB)();
};

Version

Development (host) and target OS/architectures:

Output of bazel --version: aspect 5.2.1

Version of the Aspect rules, or other relevant rules from your
WORKSPACE or MODULE.bazel file:
These are the versions inside of our own project which showed this issue, but the reproducible example is just whatever is in this repo.
rules_js = 1.23.2
rules_ts = 1.3.3
rules_swc = 1.0.0

Language(s) and/or frameworks involved:
typescript

How to reproduce

bazel build //examples/paths:compile
cat bazel-bin/examples/paths/src/modules/moduleA/index.js

The root index.js appears to be generated correctly though:

   1   │ "use strict";
   2   │ Object.defineProperty(exports, "__esModule", {
   3   │     value: true
   4   │ });
   5   │ const _moduleA = require("./modules/moduleA/index");
   6   │ (0, _moduleA.moduleA)();

### Any other information?

_No response_

What happened?

Well, this is a fun one, though for the life of me I have no obvious candidate for why.

load("@aspect_rules_ts//ts:defs.bzl", "ts_project")
load("@aspect_rules_swc//swc:defs.bzl", "swc")
load("@bazel_skylib//lib:partial.bzl", "partial")

ts_project(
    name = "src",
    srcs = [
        "src.ts",
    ],
    declaration = True,
    transpiler = partial.make(
        swc,
        source_maps = "true",
    ),
    tsconfig = "//:tsconfig",
)

Where src.ts is

console.log(1);

Under rules_swc 0.20.2 the generated src.js is:

console.log(1);


//# sourceMappingURL=src.js.map

Whereas under rules_swc 0.21.0 the output is:

console.log(1);

The sourcemap file is generated, it's just not linked in the JS output.

Version

Development (host) and target OS/architectures:

Output of bazel --version: 6.0.0

Version of the Aspect rules, or other relevant rules from your
WORKSPACE or MODULE.bazel file: rules_swc 0.20.2 and 0.21.0.

Language(s) and/or frameworks involved: TS

How to reproduce

See above :)

Any other information?

No response

Fund our work

• Sponsor our open source work by donating a bug bounty

Copied from Slack https://bazelbuild.slack.com/archives/CEZUUKQ6P/p1643627483904509

I'm trying out the SWC rules. Locally everything seems to work fine, however when enabling remote build execution I run into the following error message:

ERROR: /_work/frontend/frontend/packages/libs/icons/BUILD.bazel:7:11: Transpiling with swc //packages/libs/icons:tsconfig_transpile [swc packages/libs/icons/src/plain/Sort.tsx] failed: (Exit 34): Remote Execution Failure:

Unknown: Failed to run command: Failed to start process: fork/exec bazel-out/k8-opt-exec-EAC798B4/bin/external/aspect_rules_swc/swc/_cli_launcher.sh: no such file or directory

The action is executing the following command:

SWC_BINARY_PATH=external/swc_linux-x64-gnu/swc.linux-x64-gnu.node bazel-out/k8-opt-exec-EAC798B4-ST-0e4399772f5b/bin/external/aspect_rules_swc/swc/_cli_launcher.sh --no-swcrc packages/apps/self-billing-app/src/App.tsx --out-file bazel-out/k8-fastbuild-ST-4a519fd6d3e4/bin/packages/apps/self-billing-app/src/App.js -q

I looked into the input files of the action, specifically into the _cli_launcher.sh. This file is there, but it looks like it's a symlink to nothing?

> swc pwd
/Users/dhl/Downloads/352755f10846f9e2a50f6fc6a50dde30a7c7b04a6c0c31be3ddc49a6bcc89c64/bazel-out/k8-opt-exec-EAC798B4-ST-0e4399772f5b/bin/external/aspect_rules_swc/swc
> swc ls -l
total 0
lrw-------@  1 dhl  staff   100 Jan  1  1970 _cli_launcher.sh -> bazel-out/k8-opt-exec-EAC798B4-ST-0e4399772f5b/bin/external/aspect_rules_swc/swc/_cli_launcher.sh.ru
lrw-------@  1 dhl  staff   100 Jan  1  1970 _cli_launcher.sh.ru -> bazel-out/k8-opt-exec-EAC798B4-ST-0e4399772f5b/bin/external/aspect_rules_swc/swc/_cli_launcher.sh.ru
drwxr-xr-x@ 32 dhl  staff  1024 Jan  1  1970 _cli_launcher.sh.runfiles

I created a small repository to try out the SWC bazel rules on Buildbuddy:
https://github.com/henkerik/swc-rbe-test

The builds fails on Buildbuddy with the same error message no such file or directory as on our own Buildbarn cluster.

What happened?

Similar to ts_project which automatically defaults the tsconfig attribute to :tsconfig.json if that file exists.

Version

HEAD

How to reproduce

No response

Any other information?

No response

Fund our work

• Sponsor our open source work by donating a bug bounty

What happened?

paths resolution does not work for entries in .swcrc with keys not ending in /*. That is,
such setup works

{
  "jsc": {
    "paths": {
      "@modules/*": [
        "./modules/*"
      ]
    }
  }
}

while this one does not

{
  "jsc": {
    "paths": {
      "@modules/moduleB": [
        "./modules/moduleB"
      ]
    }
  }
}

Interestingly enough, pure swc compiler resolves such paths correctly.

Version

Development (host) and target OS/architectures: Ubuntu 20, x86_64

Output of bazel --version: bazel 6.2.1

Version of the Aspect rules, or other relevant rules from your
WORKSPACE or MODULE.bazel file: just clone the rules_swc repo

Language(s) and/or frameworks involved:

• typescript

How to reproduce

1. `git clone https://github.com/aspect-build/rules_swc.git`
2. `cd rules_swc/examples/`
3. `npm i @swc/cli @swc/[email protected]`
4. add `"scripts": {"swc": "swc paths/"}` to `examples/package.json`
5. change the content of `examples/paths/.swcrc` to


{
  "jsc": {
    "parser": {
      "syntax": "typescript"
    },
    "target": "es2021",
    "baseUrl": "./src",
    "paths": {
      "@modules/moduleB": [
        "./modules/moduleB"
      ],
      "@modules/moduleA": [
        "./modules/moduleA"
      ]
    }
  },
  "module": {
    "type": "commonjs"
  },
  "sourceMaps": true
}


6. `npm run swc` (see the output, it works correctly, e.g. `const _moduleB = require("../moduleB")`)

7. `cd ../` (now you should be in `rules_swc`)

8. `curl -L https://github.com/bazelbuild/bazel/releases/download/6.2.1/bazel-6.2.1-linux-x86_64 -o bazel`

9. `chmod +x bazel`

10. `./bazel build //examples/paths:compile`

11. `cat bazel-bin/examples/paths/src/modules/moduleA/index.js`

You can see `const _moduleB = require("@modules/moduleB");` in the output

Any other information?

No response

Follow-up to #172

The mirroring script is generating bad SHAs for at least the linux-x64-gnu platform.

It also doesn't run on OSX as there is something linux specific in the bash script.

I have a file packages/xpackage/server/src/tests/y-test.ts, which I am trying to compile with the swc_rule.

Problem
The compiled output file is empty.

Configuration

swc(
  name = "y_test_swc",
  srcs = ["y-test.ts"],
  source_maps = True,
  swcrc = "//packages/xpackage:.swcrc",
)

Possible Cause
Current subcommand being run by swc_rule:

SUBCOMMAND: # //packages/xpackage/server/src/tests:y_test_swc [action 'Transpiling with swc //packages/xpackage/server/src/tests:y_test_swc [swc packages/xpackage/server/src/tests/y-test.ts]', configuration: 2dbb605ac0825292323b7a4585cb36cd7762af7e47ba3ff3f3e09310b3ca4246, execution platform: @local_config_platform//:host]
(cd /private/var/tmp/_bazel_riyavsinha/903eebc477abc3a7df81d5ec7291fe86/execroot/workspace_name && \
  exec env - \
    SWC_BINARY_PATH=external/swc_darwin-x64/swc.darwin-x64.node \
  bazel-out/darwin-opt-exec-2B5CBBC6/bin/external/aspect_rules_swc/swc/_cli_launcher.sh --source-maps true --config-file packages/xpackage/.swcrc server/src/tests/y-test.ts --out-file bazel-out/darwin-fastbuild/bin/packages/xpackage/server/src/tests/y-test.js --no-swcrc -q)

Because the input file is being given as server/src/tests/y-test.ts instead of packages/xpackage/server/src/tests/y-test.ts (the packages/xpackage stripped away), maybe the file is not being recognized/input to swc in the first place, and so it outputs a blank file?

(There is also no error thrown for this, and only by opening the compiled file can you see that it is blank, though this may be an issue with swc?)

Let's say I have 3 packages where:

• package-a depends on package-b
• package-b depends on package-c
• package-c has no dependencies

And each of these are defined with swc_transpiler, for instance:

swc_transpiler(
    name = 'package-a',
    srcs = ['index.ts'],
    data = [
        "//package-b",
    ],
    visibility = ["//visibility:public"],
)

Running…

bazel build //package-a

…will not build package-c.

Here's a minimal reproduction: https://github.com/Nick-Mazuk/bazel-swc-deps

Currently, the swcrc must be in the source package and fails on the copy_to_bin_action step if it exists in a separate package.

Workaround is to make sure the swcrc is a generated file instead of a source file.