Ep 7 - SvelteKit bug hunt safari

Agenda for this week

1. Weekly Journal Review

   • Code Journal
   • Teaching Journal

2. Walk-through of last week

3. Walk-through of the differences between builds .403 and .420 of SvelteKit

4. Walk-through of the buggy behavior that needs to be solved.

5. Upgrade .420 to the latest .465.

6. New bug found!

7. Break time: Which to do?

   1. Downgrade SK/Vite to fix Cannot stringify a function when exporting markdown render function to +page.svelte from +page.server.js, OR
   2. Build a reproduction repo for the original page refresh bug (and potential run into the stringify bug again). Same same.

8. Research:

   • How to lock SvelteKit to a build version
     • Stackoverflow: How do I lock sveltekit down to a version?
   • Will using a Svelte store solve the stringify issue?
     • Svelte.js 3 Stores & State Management Tutorial
   • How to create a proper reproduction
     • When creating an Issue, use the Bug Report template

       Reproduction A link to a repository, or a fork of https://node.new/sveltekit, that reproduces the issue. Reproductions must be short, self-contained and correct and must not contain files or code that aren’t relevant to the issue — please do NOT just paste a link to your project. Explaining how to reproduce is generally not enough. It pushes the burden of creating a reproduction project onto a small set of volunteer maintainers and isn’t scalable. If no reproduction is provided, the issue will be closed.

     • Example procedure:
       1. Name your repro with a distinctive name so it doesn’t collide with other repros in the maintainers’ system.
       2. Start fresh:

          $ npm init svelte

       3. Select Skeleton project
       4. Select default for all options (i.e. “No”)
       5. Install dependencies with npm, NOT Yarn or pnpm. npm is the gold standard.
       6. Use minimal code and files to reproduce the Issue.
          • A “perfect” example of an Issue repro: URI Encoding inconsistent between SSR and Browser routers

9. Stringify bug:

   • A breaking change in .422 was the root cause of the issue.

     • From Issue #6007:

       Closes #5936. This behaviour is nothing more than a historical accident. It’s buggy, and there’s no reason to keep it.

       If we want routes to serve both HTML and non-HTML, #5896 is a more promising approach.

   • Apparently the solution will be to move the +page.server.js code to a +server.js file because they support returning JSON data as a Response.

10. Move the +page.server.js code to a +server.js!

    1. Add .md file in $lib
    2. Add test route.
    3. Inside test add +page.server.js that:
       • import() .md file
       • return import object to +page.svelte
    4. Inside test add +page.svelte that:
       • exports data
       • uses import object in a <svelte:component> elements

11. Update: That didn’t work.

12. Update update: Both problems only needed changes to two lines of code!

    • Turns out there’s a new way to render the code in +page.server.js before exporting it:

      lessonContent.default

      is now

      lessonContent.default.render().html

    • And you no longer need to use a dynamic component:

      <svelte:component this={data.lessonContent} />

      is now:

      {@html data.lessonContent}

    • In hindsight, checking the original theme commits for changes would have saved hours of grinding, but at least I learned some things along the say (see above).

Cleanup

• Update schedule for next stream (README.md)