bundler: Node package resolution

[MikeRomaa]

Describe the bug

I seem to get some nasty internal errors when attempting to bundle a module that imports anything from an external dependency (such as ones obtained through npm).

I wanted to use swcpack for a large project currently built on rollup and babel, but encountered similar issues. I had a suspicion it was due to the many external dependencies we have, since the swc transpiler worked perfectly fine, and the below code sample proved my theory.

Input code

// index.js
import { concat } from 'lodash';

export const test = concat(0, 1, [2, 3]);

Config

// .swcrc
{
    "jsc": {
        "target": "es5",
        "parser": {
            "syntax": "ecmascript",
            "dynamicImport": true,
            "jsx": false
        }
    },
    "module": {
        "type": "commonjs"
    }
}

// spack.config.js
const { config } = require('@swc/core/spack');
const path = require('path');

module.exports = config({
    entry: {
        pfd: path.join(__dirname, '/index.js'),
    },
    output: {
        path: path.join(__dirname, '/dist'),
        name: 'index.js',
    },
});

Playground link

No response

Expected behavior

The bundler should emit a single bundle that contains the code from any external dependencies and the program code.

Actual behavior

Running yarn spack generates an error.

❯ yarn spack
yarn run v1.22.18
$ /Users/mike/Documents/Projects/swc-test/node_modules/.bin/spack
thread '<unnamed>' panicked at 'cannot access a scoped thread local variable without calling `set` first', /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/scoped-tls-1.0.0/src/lib.rs:168:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
node:internal/process/promises:279
            triggerUncaughtException(err, true /* fromPromise */);
            ^

[Error: panic detected] { code: 'GenericFailure' }
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Version

1.3.7

Additional context

No response

[MikeRomaa]

Got a debugger going and found that this call to ScopedKey::with leads to the panic being called from the better_scoped_tls library.

swc/crates/swc_ecma_transforms_base/src/perf.rs

Line 55 in 1ed0203

HANDLER.with(|handler| {

Weirdly enough, I tried omitting the call to the handler all together and while the bundler did actually end up working, the tree shaking didn't seem to work. The final bundle included the entirety of the lodash library.

[aminya]

I could reproduce this in #6205

[snyamathi]

I can reproduce this as well - here's a pretty minimal repo:

// package.json
{
  "name": "example",
  "version": "1.0.0",
  "dependencies": {
    "@swc/cli": "^0.1.57",
    "@swc/core": "^1.3.11",
    "lodash": "^4.17.21"
  }
}

// spack.config.js
const { config } = require("@swc/core/spack");

module.exports = config({
  entry: {
    web: __dirname + "/src/web.js"
  },
  output: {
    path: __dirname + "/lib",
  },
});

// src/web.js
require('lodash/reduce');
require('lodash/set');

$ npx spack
thread '<unnamed>' panicked at 'cannot access a scoped thread local variable without calling `set` first', /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/scoped-tls-1.0.0/src/lib.rs:168:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
node:internal/process/promises:279
            triggerUncaughtException(err, true /* fromPromise */);
            ^

[Error: panic detected] { code: 'GenericFailure' }

[sciyoshi]

In case it helps debugging - this seems to have broken in @swc/core@1.2.246. @swc/core@1.2.245 does not exhibit the bug.

[MikeRomaa]

In case it helps debugging - this seems to have broken in @swc/core@1.2.246. @swc/core@1.2.245 does not exhibit the bug.

Seems to be so, but it also doesn't perform the quite necessary tree-shaking step.

[qiyueximeng]

i got this problem in @swc/core 1.3.21

[MohamedLamineAllal]

In:

"@swc/cli": "^0.1.57",
"@swc/core": "^1.3.24",

thread '<unnamed>' panicked at 'cannot access a scoped thread local variable without calling `set` first', /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/scoped-tls-1.0.1/src/lib.rs:168:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
node:internal/process/promises:289
            triggerUncaughtException(err, true /* fromPromise */);
            ^

[Error: panic detected] { code: 'GenericFailure' }

Node.js v19.3.0

[DzmitryFil]

Same. Couldn't use swc cli at all. Panics and crashes on every project i tried, while rollup/webpack/esbuild work fine.

[eliliam]

I'm hitting this same issue too, is spack/swcpack even supported anymore? I literally cannot get it to compile anything other than very basic vanilla JS. Even simple things like importing socket.io-client fails with a "failed to resolve" error, on top of that this whole issue with the scoped-tls library is causing massive headaches.

I think we all want to use spack/swcpack but in its current state it feels totally broken and unusable, especially compared to other alternatives like Webpack and Rollup. Does anyone know if any work is ongoing with spack/swcpack or if it's unofficially deprecated?

[MikeRomaa]

I'm hitting this same issue too, is spack/swcpack even supported anymore? I literally cannot get it to compile anything other than very basic vanilla JS. Even simple things like importing socket.io-client fails with a "failed to resolve" error, on top of that this whole issue with the scoped-tls library is causing massive headaches.

I think we all want to use spack/swcpack but in its current state it feels totally broken and unusable, especially compared to other alternatives like Webpack and Rollup. Does anyone know if any work is ongoing with spack/swcpack or if it's unofficially deprecated?

If you want to escape the painful grasp of Webpack/Rollup, check out esbuild. It's what I ended up going with after reaching this wall with swc and it seems to work pretty well and has a great plugin system.