Error when using version 0.4.0

[CatchABus]

Version 0.3.0 worked just fine but when I installed new version I received the following error.

Uncaught (in promise) TypeError: Cannot read property '$$' of undefined
    at et (index.mjs:1)
    at new wt (index.mjs:1)
    at create_if_block (App.svelte:13)
    at Object.update [as p] (App.svelte:30)
    at update (index.mjs:929)
    at flush (index.mjs:897)

[zerodevx]

Can I check which bundler (rollup/webpack/something else) you're using?

[CatchABus]

@zerodevx I'm using webpack 5 with svelte-loader.

[zerodevx]

Where (and how) did this error appear? In the browser JS console or in terminal dev server? Does this appear when a toast is pushed?

Uncaught (in promise) TypeError: Cannot read property '$$' of undefined
at et (index.mjs:1)
at new wt (index.mjs:1)

I find it a little strange that it throws at index.mjs - that's the compiled code that's intended for non-Svelte applications.

[CatchABus]

Where (and how) did this error appear? In the browser JS console or in terminal dev server? Does this appear when a toast is pushed?

This appears in browser when loading app for first time.
It all begins when rendering SvelteToast component.
e.g. <SvelteToast options={toastOptions}/>

There is also the webpack dev version of error shown on reload:

Failed to init component
<App>
TypeError: Cannot read property '$$' of undefined
    at et (http://localhost:8080/build/bundle.js:5277:4398)
    at new wt (http://localhost:8080/build/bundle.js:5277:15123)
    at create_if_block (http://localhost:8080/build/bundle.6798e338e525a967ff8f.hot-update.js:56:16)
    at create_fragment (http://localhost:8080/build/bundle.6798e338e525a967ff8f.hot-update.js:350:47)
    at init (http://localhost:8080/build/bundle.js:58239:37)
    at new App (http://localhost:8080/build/bundle.6798e338e525a967ff8f.hot-update.js:493:56)
    at createComponent (http://localhost:8080/build/bundle.js:52546:20)
    at App.targetCmp.$replace (http://localhost:8080/build/bundle.js:52593:15)
    at refreshComponent (http://localhost:8080/build/bundle.js:52149:28)
    at ProxyAdapterDom.rerender (http://localhost:8080/build/bundle.js:51936:5)

[zerodevx]

In your source, can you try importing the package like this:

<script>
import { SvelteToast } from '@zerodevx/svelte-toast/src'

...
</script>

<SvelteToast options={toastOptions} />

and let me know what happens?

[CatchABus]

I receive this:
Module not found: Error: Package path ./src is not exported from package /home/myuser/web_v2/node_modules/@zerodevx/svelte-toast

However, I modified svelte-toast package.json inside node_modules to test source files just as you suggest.Fileindex.jsfromsrc` seems to be working without errors, so the problem occurs solely with bundled files on Google Chrome.
It's strange though. I never had any issues with package builds before.

[zerodevx]

AFAIK svelte-loader for webpack should use the svelte field in package.json as the module entry point.

"svelte": "src/index.js",
"module": "dist/index.mjs",
"main": "dist/index.js",

For non-Svelte apps, webpack will use the module field instead. I'm not sure why this is happening TBH.

Could you help test one more time: this time, can you pin svelte-toast to v0.3.0? I just want to be super sure that this is introduced because of v0.3.0 -> v0.4.0.

[CatchABus]

I installed 0.3.0 using npm i @zerodevx/svelte-toast@0.3.0 and everything went smoothly. No errors.

[zerodevx]

Thanks so much for the info. Let me check again and get back to you.

[CatchABus]

Thanks so much for the info. Let me check again and get back to you.

After meddling with bundled file, I found out this line is what causes the issue.
const d=e.$$={fragment:null,ctx:null,props:c,update:t,not_equal:a,bound:r(),on_mount:[],on_destroy:[],on_disconnect:[],before_update:[],after_update:[],context:new Map(f?f.$$.context:n.context||[]),callbacks:r(),dirty:u,skip_bound:!1,root:n.target||f.$$.root};
The following part causes error:
root:n.target||f.$$.root

This property did not exist in version 0.3.0 bundle. It seems that f is undefined at this place.

[CatchABus]

Svelte recently commited these changes: sveltejs/svelte@5cfefeb#diff-da9bae4e28c441de5ba3a074e30775fe69109100b3d921ad8f2592d93cd67b7f

This patch contains a new root property that gets its value from target option and it's the same property that throws error in my bundle. Could it be that plugin target property has somehow a conflict with svelte target option?

EDITED: I have also created an issue at sveltejs here: sveltejs/svelte#6584

[CatchABus]

@zerodevx In my ticket on sveltejs, one reported that updating the following dependencies to versions below (at least) solved issue caused on build.

{
  "@rollup/plugin-node-resolve": "^13.0.0",
  "rollup": "^2.54.0",
  "rollup-plugin-svelte": "^7.1.0",
  "svelte": "^3.41.0"
}

Problem first occurred when plugin dependencies were updated right before 0.4.0 release, so I assume it's svelte environment that causes this. Source files worked fine for me because I used an older svelte version in addition to index.mjs.

[zerodevx]

Thanks so much for investigating. Can I just check that in your webpack.config.js, you have something like this declared?

resolve: {
  alias: {
    svelte: path.resolve('node_modules', 'svelte')
  },
  extensions: ['.mjs', '.js', '.svelte'],
  mainFields: ['svelte', 'browser', 'module', 'main']
},

I just want to make sure that your Svelte app is using the component source.

[CatchABus]

This is what I'm using according to sveltejs/template-webpack:

  resolve: {
    alias: {
      svelte: path.dirname(require.resolve("svelte/package.json"))
    },
    extensions: [".mjs", ".js", ".svelte"],
    mainFields: ["svelte", "browser", "module", "main"]
  },

I also tried alias with path.resolve('node_modules', 'svelte') but error still occurs.

[LucianVoju]

Hello,

I got the same error with svelteKit but resolved after updating to 3.41.0

[zerodevx]

So, I think there are two issues here:

1. webpack + svelte-loader is picking up the compiled file at dist/index.mjs instead of the source entry-point src/index.js. I think I know why and I'll commit a fix.

2. A regression was introduced in the Svelte v3.40.2 release, which is fixed from v3.41.0.

@dimitrisrk - I'll release a patch version in a bit that should solve your issue; on your end, just update your npm dependencies (specifically @zerodevx/svelte-toast -> 0.4.1 and svelte -> 3.41.0) and that should theoretically fix everything nicely.

@LucianVoju - can I check what bundler setup you're using?

[CatchABus]

@zerodevx Everything works smoothly. Thank you very much!

[LucianVoju]

Hello,

Updated to 0.4.1 but sill got the typescript error.

My setup is:
`import adapter from '@sveltejs/adapter-node';
import preprocess from "svelte-preprocess";
import tailwindcss from 'tailwindcss';
import autoprefixer from 'autoprefixer';
import path from 'path';

/** @type {import('@sveltejs/kit').Config} */
const config = {
preprocess: [
preprocess({
postcss: {
plugins: [
tailwindcss,
autoprefixer
],
}
}),
],
kit: {
// hydrate the

element in src/app.html
target: '#svelte',
vite: {
optimizeDeps: {
include: ['svelte-hero-icons'],
},
resolve: {
alias: {
$pages: path.resolve('./src/pages'),
$components: path.resolve('./src/components'),
$stores: path.resolve('./src/stores')
}
},

	},
	adapter: adapter({
		// default options are shown
		out: 'build'
	})
}

};

export default config;

[zerodevx]

Moving the previous comment to the correct issue.

So, I think there are two issues here:

1. webpack + svelte-loader is picking up the compiled file at dist/index.mjs instead of the source entry-point src/index.js. I think I know why and I'll commit a fix.
2. A regression was introduced in the Svelte v3.40.2 release, which is fixed from v3.41.0.

For posterity, the reason for reverting #12 is because adding the exports field in package.json forces webpack to disregard the de-facto mainFields: ["svelte", "browser", "module", "main"] resolution behaviour. If there are any issues working with SvelteKit - I can't imagine that it's not fixed by now - it should be fixed in SvelteKit rather than at the component authors' end.

Closing this issue for now - but feel free to re-open if you encounter further problems.