[Bug]: paths do not resolve correctly without /*

[mksmtn]

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

[alexeagle]

Hi @mksmtn - could you try reproducing this with the swcx binary, which is the one that has no NodeJS involved? From your repro, I can't tell if it's a bug here in rules_swc, or a problem with the pure-Rust swcx program we spawn.