[Wrong] Es6/nodenext module only has a field named resolveFully and you should remove other fields.

[DuCanhGH]

Describe the bug

Since @swc/core@1.3.80, my project - @ducanh2912/next-pwa - has been seeing this issue:

For me - building the package using rollup with @rollup/plugin-swc:

src/index.ts → dist/index.cjs, dist/index.module.js...
[!] (plugin swc) Error: unknown field `lazy`, expected `resolveFully` at line 1 column 444
src/index.ts
Error: unknown field `lazy`, expected `resolveFully` at line 1 column 444

For people who use my project:

 x (pwa) Failed to build the fallback worker.
 x (pwa) assets by status 268 bytes [cached] 1 asset
./node_modules/.pnpm/@ducanh2912+next-pwa@9.7.0_next@13.5.1_webpack@5.88.2/node_...(truncated) 39 bytes [built] [code generated] [1 error]

ERROR in ./node_modules/.pnpm/@ducanh2912+next-pwa@9.7.0_next@13.5.1_webpack@5.88.2/node_modules/@ducanh2912/next-pwa/dist/fallback.js
Module build failed (from ./node_modules/.pnpm/@ducanh2912+next-pwa@9.7.0_next@13.5.1_webpack@5.88.2/node_modules/@ducanh2912/next-pwa/dist/swc-loader.cjs):
Error: unknown field `lazy`, expected `resolveFully` at line 1 column 639

webpack 5.86.0 compiled with 1 error in 238 ms

This seems to only stop happening if I remove module.lazy and module.noInterop from .swcrc, but they don't seem to have been removed at all, which tells me that this is likely a bug.

Input code

Link to the repo: https://github.com/DuCanhGH/next-pwa/tree/master/packages/next-pwa

Code compiled on users' end:

self.fallback = async (request) => {
  // https://developer.mozilla.org/en-US/docs/Web/API/RequestDestination
  const { destination, url } = request;
  const fallbackUrl: Partial<Record<RequestDestination, string | undefined>> = {
    document: process.env.__PWA_FALLBACK_DOCUMENT__,
    image: process.env.__PWA_FALLBACK_IMAGE__,
    audio: process.env.__PWA_FALLBACK_AUDIO__,
    video: process.env.__PWA_FALLBACK_VIDEO__,
    font: process.env.__PWA_FALLBACK_FONT__,
  };
  const fallbackResponse = fallbackUrl[destination];
  if (fallbackResponse) {
    return caches.match(fallbackResponse, {
      ignoreSearch: true,
    });
  }
  if (
    destination === "" &&
    process.env.__PWA_FALLBACK_DATA__ &&
    url.match(/\/_next\/data\/.+\/.+\.json$/i)
  ) {
    return caches.match(process.env.__PWA_FALLBACK_DATA__, {
      ignoreSearch: true,
    });
  }
  return Response.error();
};

// Mark file as module.
export {};

Config

Config used to compile the package itself:

// @ts-check
/**
 * @type {import("@swc/core").Config}
 */
export const swcConfig = {
  module: {
    type: "nodenext",
    lazy: true,
    importInterop: "swc",
  },
  jsc: {
    minify: {
      compress: {
        ecma: 5,
        comparisons: false,
        inline: 2,
      },
      mangle: {
        safari10: true,
      },
      format: {
        ecma: 5,
        safari10: true,
        comments: false,
        asciiOnly: true,
      },
    },
    parser: {
      syntax: "typescript",
      tsx: false,
      dynamicImport: true,
      decorators: false,
    },
    transform: {
      react: undefined,
    },
    target: "esnext",
    loose: false,
  },
};

Config used to compile on users' end:

import type { Options } from "@swc/core";

export const defaultSwcRc: Options = {
  module: {
    type: "es6",
    lazy: true,
    noInterop: true,
  },
  jsc: {
    parser: {
      syntax: "typescript",
      tsx: true,
      dynamicImport: true,
      decorators: false,
    },
    transform: {
      react: {
        runtime: "automatic",
      },
    },
    loose: false,
  },
  minify: false,
};

Playground link

https://play.swc.rs/?version=1.3.80&code=H4sIAAAAAAAAA5VTwW4aMRC98xWjqIpApfadZJG2gVSooSASmkOJLMeeBTdee2t7Udp0%2F70GdpOoSBvl4Iv95r03bzwedUYyrvU9Fw%2BQAPe%2FjYCuw18l%2BtCDZAhPHQBKYRNC4QeUStyitgU6kts%2FSmtOrFtTNJ%2BW11Ra4ekt3tN0PqGLA8coHmV4UNZEImGND%2FAE8uW2D6XTUEXxWvXsGdcYWzo9gDl3QXF9vkBhnTw%2Fpu%2BDD06ZNfyF0kjMlEE5HEbeXQcA0VyZowkDKJwV6D1BsyWMzW9TdpleXX1OL76y0exiOR1%2Fu2Gsvy9SOV9ja8Vkmn4ZN3BeSmVb4elyNJk18K2S2A7%2FPhmNn%2BGZfcP95axxXh2HuEBfxAuMgbzK9cerSdztilQG3f9LenWEDkPpDAguNuhJzoPYHGH7NTYyrY11eI3cic0Agivx0EbV2%2BlUtdZhNi8mIEkSODmB09P9S9us0puUsQYYP1HtiK4oM%2FgYVlTywFeUfNwf8tNb84GqXoS3NfSm4ns6rAWacAg6Z103PscBdeJWTbl7gExpjJsHuZWlRtLBx8K6uCXV2T%2B8Oe6unwMAAA%3D%3D&config=H4sIAAAAAAAAA1WPQQ7DIAwE731FxLnnHvqDPsMijkQFGNlGCq34eyFBaXLcWWnH%2Ft6myQSas0fznL4ttawl9WRQHua%2BIw%2Bf0pByxkEivaIiUxq40dor8xb7n0rAgnzkRqREhbXPd41YdkmHpatlvWgamtESgxJLaxbwgltTxx3KEGUhDmcJI1g9gY5yVBe2vyArBVBnzajrZdETCZ5c%2B1vBRbeUA9cfInoy3ToBAAA%3D

SWC Info output

Operating System:
    Platform: linux
    Arch: x64
    Machine Type: x86_64
    Version: #1 SMP PREEMPT_DYNAMIC Wed, 06 Sep 2023 21:01:01 +0000
    CPU: (12 cores)
        Models: AMD Ryzen 5 5500

Binaries:
    Node: 18.16.0
    npm: 9.5.1
    Yarn: 1.22.19
    pnpm: 8.7.5

Relevant Packages:
    @swc/core: 1.3.86
    @swc/helpers: N/A
    @swc/types: N/A
    typescript: 5.3.0-dev.20230915
    next: 13.4.19

SWC Config:
    output: N/A
    .swcrc path: N/A

Next.js info:
    output: N/A

Expected behavior

This issue shouldn't happen, and the code should be compiled successfully like in @swc/core@1.3.78 and below.

Actual behavior

The error happens as described in section "Describe the bug".

Version

1.3.86

Additional context

On users' end, seems that even installing @swc/core@1.3.8x works (this forces next-pwa to resolve to that swc instead of Next's internal swc), but this is not the case for the package itself. Only by pinning @swc/core to 1.3.78 can I get it to build.

[kdy1]

Please search for issues. I'm on mobile so linking them is hard.

[kdy1]

#7963

[DuCanhGH]

@kdy1 thanks, that issue was closed and the problem was still happening in the latest swc so I thought there had been no issues opened on that.
Perhaps swc's TypeScript definition can be updated to reflect the change? (seems that this is planned looking at the issue)

[kdy1]

It's closed becauae it's not a bug. It's about a wrong configuration.

[DuCanhGH]

@kdy1 yeah I was just trying to reason for my opening a new issue; however, maybe it'd be nice to change the types so that the user would know when they provide an invalid configuration? Like, I think there should be red squiggles when the user tries to use both module: "nodenext" // and some other module types and some options like lazy, strict, noInterop,... :)

[maiconcarraro]

@kdy1 what @DuCanhGH is talking about relates to this change

nodenext can only follow EsModuleConfig now, but depending on the configuration it should allow the other options... in your PR there are only update to fixtures using es6 type, not nodenext... so maybe I'm missing something

[kdy1]

I can change the type if required, but in future.

[meabed]

Not sure if it's related, but After updating to "@swc/core": "1.3.88"
I get another 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

[Yovach]

Not sure if it's related, but After updating to "@swc/core": "1.3.88" I get another 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

swc-project/swc-node#732 seems to be the same issue

[kdy1]

I think this is an improvement of the wrong config detection.

[yeliex]

It is better to be a minor or major update because it broken many other packages such as swc-node, the currently only usable register and loader for swc in node

[kdy1]

I don't consider an improved validation as a breaking change.

[javadoug]

I don't consider an improved validation as a breaking change.

This is the very definition of breaking change. If a library makes a change that breaks consumers - that is a breaking change.

Your "consideration" should be data driven. How you "label" the substance of the change is not relevant to the fact that this is breaking everyone who uses SWC. I would suggest you reclassify this as a breaking change.

[kdy1]

So if a bug made a program of user work where it should not, the bug should never be fixed without marking it as a breaking change, right?
Do you really think this makes sense?

[ehaynes99]

If you have years of precedent, and suddenly cause all of those applications to crash in a point release, then yes, it should be marked as a breaking change. It's reach is much wider than just invoking ts-node directly. npm will update ^1.3.whatever to the current version on any change that rebuilds the lockfile. I have had to lock 50+ repositories at 1.3.82 now. I've long been a champion for swc, but the perception among the team is that "swc keeps breaking". The workflow goes something like:

• someone installs ANY npm package
• the ci pipeline attempts to run unit tests, which use @swc/jest as the transfomer
• this error is emitted: Error: Jest: Failed to parse the TypeScript config file /home/ehaynes99/projects/some-library/jest.config.ts

This happens because the tsconfig.json contains "ts-node": { "swc": true }. Apparently, jest uses ts-node under the hood when the jest config is a .ts file.

├─┬ jest@29.7.0
│ └─┬ @jest/core@29.7.0
│   └─┬ jest-config@29.7.0
│     └── ts-node@10.9.1 deduped

A random developer who installed some completely unrelated dependency in their project won't know that the root cause is a "validation improvement".

Can this not emit a warning and ignore extraneous values? serde has direct support for capturing those values: serde-rs/serde#941 (comment)

#[macro_use]
extern crate serde_derive;

extern crate serde;
extern crate serde_json;

use std::collections::BTreeMap as Map;
use serde_json::Value;

#[derive(Serialize, Deserialize)]
struct S {
    a: u32,
    b: String,
    #[serde(flatten)]
    other: Map<String, Value>,
}

[kdy1]

I expected ts-node to fix it more promptly.
I'll change this error to warning

[ehaynes99]

I don't know why they haven't... TypeStrong/ts-node#2070
A fix was merged a month ago, but no release since July. It would have to trickle down to jest and others from there, though, so could be a while. :-(

Really appreciate this!

[swc-bot]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.