Compatibility with import.meta

[braebo]

The primary discussion on Vite: vitejs/vite#1955.

Based on vitejs/vite#1955 (comment), the community seems to have settled around vite-jest, available on NPM npmjs.com/package/vite-jest.

@rossyman - I'm thinking this might be the move, what do you think?

As an aside- it could be a good idea to submit a PR for a Svelte example if nobody has jumped on that yet.

[rossyman]

I'll take a look into this and see what we can do

[rossyman]

After looking into this further, vite-jest is still in it's POC phase, meaning they're still in early development and most likely need to iron out some issues before adoption. Let's keep this issue open to track the progress of vite-jest and when appropriate, look into it's utilisation.

On the point of creating a svelte example, this is something we can most likely do.

Thoughts? @fractalhq

[rossyman]

After even more investigation, here are a few points I've found:

• We use svelte-jester to transform our .svelte components into Jest readable code.
• svelte-jester requires ^v26 of Jest, whereas vite-jest requires ^v27, creating a blocking dependency for this task. This issue can be tracked here: Are there plans to support jest ^27? svelteness/svelte-jester#55
• As-of-now, vite-jest, only seems to have explicit support for React and Vue, so a POC specifically for svelte seems to be in order, as we don't fully know how they play ball with each other.
• We should investigate how svelte-jester and vite-jest interact with each other once svelte-jester is updated to support ^v27 of Jest, or look into an alternative to svelte-jester as a means to allow developers to use Vite specific features.

[rossyman]

Opened a related issue in vite-jest to query how we could add svelte specific support in co-ordination with our current transformer setup with svelte-jester:

• Support for SvelteKit projects haoqunjiang/vite-jest#15

[patrickleet]

I got import.meta working by using esbuild-jest

"transform": {
    "^.+\\.svelte$": "svelte-jester",
    "^.+\\.(ts|tsx|js|jsx)$":  ["esbuild-jest"]
  },

There were a slew of other problems beyond that - such as mocking sveltekit's default context so things like $app/env and the default stores that are stored in the __svelte__ wouldn't blow up.

Which were solved by mocks like these:

jest.mock('$app/env.js', () => ({
  amp: false,
  browser: true,
  dev: true,
  mode: 'test'
}))

jest.mock('$app/navigation.js', () => ({
  goto: jest.fn()
}))

jest.mock('svelte', () => {
  const { writable } = require('svelte/store')
  const actualSvelte = jest.requireActual('svelte')
  const fakeGetContext = jest.fn((name) => {
    if (name === '__svelte__') {
      return fakeSvelteKitContext
    }
  })
  const fakeSvelteKitContext = {
    page: writable({
      path: '/'
    }),
    navigating: writable(false)
  }

  const mockedSvelteKit = {
    ...actualSvelte,
    getContext: fakeGetContext,
  }
  return mockedSvelteKit
})

Mocking the sveltekit context was a bit tricky, so wanted to share for anyone else who comes down this path.

This is set up and working in this example repo here: https://github.com/CloudNativeEntrepreneur/sveltekit-eventsourced-funnel