SWC ignore .swcrc config

[Kaizer69]

Desired Behavior

When use ts-node, you should use default swcrc that ts-node create, but if is present a .swcrc file, you should use that file.

Is this request related to a problem?

Yes, because if I have a JS file with private members (hash # char), SWC wont compile

[cspotcode]

What's your .swcrc look like?

[Kaizer69]

{
  "$schema": "https://json.schemastore.org/swcrc",
  "exclude": [".*.js$", ".*.map$"], <<<<<<<<<<-------------
  "jsc": {
    "parser": {
      "syntax": "ecmascript",
      "jsx": false,
      "dynamicImport": false,
      "privateMethod": true, <<<<<<<<<<-------------
      "functionBind": false,
      "exportDefaultFrom": false,
      "exportNamespaceFrom": false,
      "decorators": true,
      "decoratorsBeforeExport": false,
      "topLevelAwait": false,
      "importMeta": false
    },
  },
}

I try to pure an invalid .swcrc and ts-node start without problems. The configuration is skipped.
I want to exclude JS (that SWC can parse for private methods) or use privateMethod flag of SWC.

Is possibile enable swcrc flag (actually swcrc: false) here?

Here the error using SWC:

........@swc\helpers\lib\_class_check_private_static_access.js:8
        throw new TypeError("Private static access of wrong provenance");
              ^
TypeError: Private static access of wrong provenance

[cspotcode]

Is there a minimal example of the .js file raising this error?

[Kaizer69]

I cannot provide the example, because the JS lib that I've use is highly obfuscated, so it's difficult extract only the private part.

[cspotcode]

It can be a new one, just needs to be an example that can be used to test with. Requesting a minimal reproducible example is common practice in open-source: https://en.wikipedia.org/wiki/Minimal_reproducible_example

[vinczebalazs]

I have the same problem also, any .swcrc config fileis ignored.

[cajoy]

The same here

[falkenhawk]

Is it really necessary for ts-node to tell swc to ignore .swcrc altogether by this setting?
https://github.com/TypeStrong/ts-node/blob/main/src/transpilers/swc.ts#L222

[radriaanse]

Slightly different use case here, using the .swcrc file to specify path mappings like;

  "jsc": {
    "paths": {
      "@/some/*": ["thing/*"],
    },

ts-node could optionally allow specifying these (or fetching them from the tsconfig.json) but if we could enable loading the .swcrc ts-node doesn't have to be updated every time new options become available in swc.

[mmazzarolo]

For what is worth, for a quick patch, changing swcrc: false to true using patch-package is enough to make it work.

Diff here:

diff --git a/node_modules/ts-node/dist/transpilers/swc.js b/node_modules/ts-node/dist/transpilers/swc.js
index eeddd4f..563c253 100644
--- a/node_modules/ts-node/dist/transpilers/swc.js
+++ b/node_modules/ts-node/dist/transpilers/swc.js
@@ -165,7 +165,7 @@ function createSwcOptions(compilerOptions, nodeModuleEmitKind, swcInstance, swcD
                     ignoreDynamic: nodeModuleEmitKind === 'nodecjs',
                 }
                 : undefined,
-            swcrc: false,
+            swcrc: true,
             jsc: {
                 externalHelpers: importHelpers,
                 parser: {

[vagusX]

I think it's necessary for ts-node to expose the reading behavior of swc, especially since the @swc/core@1.3.40 version was recently updated with the useDefineForClassFields option enabled by default, which has caused inconsistent compilation behavior for class properties compared to tsc.

[vagusX]

Otherwise shall we disable useDefineForClassFields firstly? #1968

[rafaelliu]

Also interested in this, same issue with useDefineForClassFields. Merging a explicitly defined .swcrc would be nice, but just exposing useDefineForClassFields would do it on my case