SWC: unknown field noInterop, expected resolveFully

[meabed]

Using "@swc/core": "1.3.88", there is error with noInterop

JSON: {"sourceMaps":true,"module":{"noInterop":false,"type":"es6","strictMode":true,"ignoreDynamic":false},"swcrc":false,"jsc":{"parser":{"syntax":"typescript","tsx":false,"dynamicImport":true,"importAssertions":true},"target":"es2015","transform":{"legacyDecorator":true,"react":{"throwIfNamespace":false,"useBuiltins":false}},"keepClassNames":false,"experimental":{"keepImportAssertions":true}}}

Caused by:
    unknown field `noInterop`, expected `resolveFully` at line 1 column 391

Probably similar fix as: #2062

Might be related:

• [Wrong] Es6/nodenext module only has a field named resolveFully and you should remove other fields. swc-project/swc#7979
• [Wrong] ESM module type does not support fields from common-js swc-project/swc#7963

[RomainLanz]

You have to stay to an older version of @swc/core or monkey patch the ts-node file until there is a new release that publishes the fix.

[JesseObrien]

Also having this issue with @swc/core@1.3.89.

[RomainLanz]

That's normal. The issue is not on @swc/core side but on ts-node. They have to push a release to make it work.

[niieani]

It would be great if there was a way to pass in SWC options from an ENV VAR or something to workaround those kinds of issues in the future.

[thetoxicavenger]

can we expect a fix on this soon? this blocks speeding up cdk apps via swc transpilation, unfortunately :/ https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk/README.md#changing-the-default-typescript-transpiler

[thetoxicavenger]

You have to stay to an older version of @swc/core or monkey patch the ts-node file until there is a new release that publishes the fix.

@RomainLanz do you know what version works?

[thetoxicavenger]

just checked, @swc/core 1.3.82 works

[RomainLanz]

Yes, I am also forcing to 1.3.82.

You can also use patch-package to monkey patch the dependency on the fly.

[jtmueller]

That's normal. The issue is not on @swc/core side but on ts-node. They have to push a release to make it work.

I agree that an update to ts-node is the most practical fix, but it kind of looks like swc broke backwards compatibility by throwing an error when it encounters a no-longer-supported option, when it should have silently ignored that option.

Why is "noInterop":false being treated any differently than not specifying noInterop? Logically the outcome is the same, so it looks like an swc bug - it's not ts-node's fault that swc broke backwards-compatibilty.

[javadoug]

The SWC should have released semver major to prevent breaking all ts-node consumers who use swc.

Workaround for me was to use resolutions and overrides in package.json to force downgrade of all transient dependencies of @swc/core until a ts-node can release with the update.

{
    resolutions: { "@swc/core": "1.2.82" },
    overrides: { "@swc/core": "1.2.82" }
}

[jbinard]

It looks like #2062 fixes this issue but there was no new release since July. Can you publish a new release to fix it ?

[dgadelha]

If anybody doesn't need any specific ts-node features, install the @swc-node/register package and replace ts-node with it according to the documentation:

npm i -D @swc-node/register
node -r @swc-node/register script.ts
node --loader @swc-node/register/esm script.ts # for esm project

[kkimdev]

@cspotcode Friendly ping?

[jacoblee93]

Bump as well!

[fohanist]

It does not work with the following versions either.

{
  "@swc/core": "^1.3.93",
  "ts-node": "^10.9.1"
}

[xobotyi]

same here, downgraded @swc/core to "1.3.82"

[przemyslawzalewski]

FYI: The latest @swc/core (at least ^1.3.94) no longer errors out on the unknown fields as the above issue has been resolved via swc-project/swc#8163 🎉