Line after `console.log` gets skipped.

[VimHax]

Describe the bug

<script lang="ts">
	console.log(null!, new Date());
	console.log('Foo');
	console.log('Bar');
</script>

When executing this code, Foo does not get printed but Bar does. It seems like no matter what the line after the initial console.log is, it gets skipped. Looking at the generated code the Foo line isn't even there.

import {S as s, i as o, s as t} from "../chunks/index.847936d9.js";
function l(e) {
    return console.log(null, new Date),
    console.log("Bar"),
    []
}
class r extends s {
    constructor(n) {
        super(),
        o(this, n, l, null, t, {})
    }
}
export {r as default};

Reproduction

https://github.com/VimHax/Svelte-Bug

This bug only happens in a release build. Simply run the following commands after cloning.

npm install
npm run build
npm run preview

When you load the website, both in the browser console and server console, you will not see Foo getting printed. The logs should look something like below;

null 2023-03-23T08:37:20.392Z
Bar

Logs

No response

System Info

System:
    OS: Linux 6.1 Fedora Linux 37 (Workstation Edition)
    CPU: (12) x64 Intel(R) Core(TM) i5-10400F CPU @ 2.90GHz
    Memory: 6.28 GB / 15.55 GB
    Container: Yes
    Shell: 3.6.0 - /usr/bin/fish
  Binaries:
    Node: 16.19.1 - ~/.nvm/versions/node/v16.19.1/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 8.19.3 - ~/.nvm/versions/node/v16.19.1/bin/npm
  Browsers:
    Firefox: 110.0
  npmPackages:
    @sveltejs/adapter-auto: ^2.0.0 => 2.0.0 
    @sveltejs/kit: ^1.13.0 => 1.13.0 
    svelte: ^3.57.0 => 3.57.0 
    vite: ^4.2.1 => 4.2.1

Severity

annoyance

Additional Information

No response

[dummdidumm]

This seems to happen only with lang="ts" at the top, which triggers vitePreprocess - the bug seems to be somewhere in there, it doesn't happen with svelte-preprocess, which makes me suspect Vite or ESbuild as the culprit. cc @dominikg @bluwy

[dominikg]

ok, this is kind of wild.

vitePreprocess uses esbuild to transpile, and that includes pure annotations.

<script lang="ts">
console.log(null!,new Date());
console.log("1")
</script>

leads to

<script lang="ts">console.log(null, /* @__PURE__ */ new Date());
console.log("1");
</script>

which the svelte compiler turns into the following js

function instance($$self) {
	console.log(null, new Date()); /* @__PURE__ */
	console.log("1");
	return [];
}

repl

notice how the pure annotation has moved from preceding the new Date() to preceding the next console.log

So far i can only assume that the subsequent bundling during build takes this as an invitation to strip the console statement.

[dominikg]

workaround: strip the pure annotations with another preprocessor. 🙈

// svelte.config.js
import { vitePreprocess } from '@sveltejs/vite-plugin-svelte'
import MagicString from 'magic-string';
import path from 'path';
export default {
  preprocess: [
    vitePreprocess(),
    {
      script({ content, filename }) {
        if(!content?.includes('__PURE__')){
          return { code: content }
        }
        const s = new MagicString(content);
        s.replace(/\/\* [@#]__PURE__ \*\//g,'');
        return {
          code: s.toString(),
          map: s.generateDecodedMap({
            source: filename ? path.basename(filename) : undefined,
            hires: true
          })
        };
      }
    }
  ]
}

[baconpat]

I ran into this today. Only it wasn't a console.log that got removed, but an important state variable being changed. Just so happened to be the next line of code after a function call that was being passed new Date() as an inline argument.

[dominikg]

Thank you for reporting @baconpat Can you share example code that caused it and does above workaround help you?

Instead of MagicString you can also use a plain regex replace with a similar amount of whitespace and keep the sourcemap.

[baconpat]

Yes, the above workaround (I just used a plain regex instead of MagicString as you mentioned) does appear to work.

One important thing I realized while pulling out this example – if the new Date() argument is the first argument to the function then there is no issue. It's only when new Date() is the second argument (and likely any later argument but I didn't actually test that) that the next line of code is affected.

It's the call to someFnThatWantsADate in the code below that results in the issue:

<script lang="ts">
  import { applyAction, enhance, type SubmitFunction } from "$app/forms";  
  import type { ActionData } from "./handle-form/$types";

  export let form: ActionData | undefined;
  let submittingForm = false;

  const someFnThatWantsADate = async (arg1: string, date: Date) => {
    console.log("The date", date, "the string", arg1);
  };

  const submitForm: SubmitFunction = () => {
    submittingForm = true;

    return async (response) => {
      // Passing `new Date()` as anything other than the first argument seems to
      // result in the code corruption
      await someFnThatWantsADate("foo", new Date());

      // The following line should result in generated JavaScript that sets the
      // submittingForm state, resulting in a re-render of the compononet. But
      // that generated function call gets removed due to the `new Date()` being
      // passed as an argument above
      submittingForm = false;

      await applyAction(response.result);
    };
  };
</script>

<form method="POST" action="/handle-form" use:enhance={submitForm}>
  <input type="text" name="firstName" value={form?.data?.firstName ?? ""} disabled={submittingForm} />
  {#if submittingForm}
    <span>Submitting...</span>
  {:else}
    <button>Submit</button>
  {/if}
</form>

Here's what the pertinent lines look like from the generated JavaScript (in Chrome DevTools), first without the workaround:

await i("foo", new Date),
e = !1,

and then with the workaround in place:

await i("foo", new Date),
a(1, e = !1),

You can see that the fixed version wraps the assignment with a function call, which I'm assuming is the thing that's triggering the state change.

[dominikg]

vite-plugin-svelte@2.0.4 has been released and strips these dangling pure comments. Please update and report back if it works for you.

[baconpat]

@dominikg - Yes! I was able to remove the workaround code after upgrading to vite-plugin-svelte@2.0.4 and the issue was gone. Thank you!

[benmccann]

This is fixed in code-red 1.0.1. You will need to use Svelte 4 to get the fix