svelte-hmr

• accept object argument to makeHot 702eb67
• fix Snowpack support 5d4e865

https://github.com/rixo/svelte-hmr/compare/v0.10.3...v0.11.0

• fix compatibility with svelte-loader-hot c726906

https://github.com/rixo/svelte-hmr/compare/v0.10.2...v0.10.3

• fix: update proxy to include $$set that was added in svelte 3.24.1 (fix #17) (thanks @dominikg)

https://github.com/rixo/svelte-hmr/compare/v0.10.1...v0.10.2

• better document HMR behaviour 175e57e
• BREAKING noPreserveState don't preserve internal state of props either anymore 6c61ddf
• expose adapter path (for vite + pnpm) b4fb87c

https://github.com/rixo/svelte-hmr/compare/v0.9.0...v0.10.0-0

• update readme: add what is hmr and mention svite d24f163

https://github.com/rixo/svelte-hmr/compare/v0.9.0-1...v0.9.0

• add vite support 52339e3

https://github.com/rixo/svelte-hmr/compare/v0.8.0...v0.9.0-0

• add injectCss option to avoid recreating components when only css changes (only with rollup-plugin-hot for now) c3b9863

https://github.com/rixo/svelte-hmr/compare/v0.6.0...v0.7.0

• better Svelte CSS support: remove CSS of previous version of the component on HMR update

• add link to sapper#rollup

• support for accessors and named exports (from context="module")
• add options acceptNamedExports and acceptAccessors

By default, modules of components with accessors (accessors compile option or <svelte:options accessors={true} /> are not accepted anymore. This means that an HMR update will bubble to all the modules importing such a component when it changes (hence consumer modules will be reloaded too). Without this, changes to accessible props or named exports wouldn't be reflected in consumer (especially consumer Svelte components).

acceptNamedExports and acceptAccessors have been added to bypass this behaviour (but many edge cases can't be properly handed by HMR).

• real support for preservation of local state & reactive expressions (thanks to svelte#3822)

Fix Svelte 3.16+ support.

Preservation of local state and reactive blocks across HMR updates is still very flacky (read mostly broken). Fortunately, this will be fixable soon, when PR #3882 gets merged.