HMR behaviour

[Xazzzi]

Hi! I'd like to ask for some help with configuring/understanding es hmr.
Very minimal example:

// index.tsx
import React from 'react';
import ReactDOM from 'react-dom';
import Component from './component';
import { loggedIn } from './session';
ReactDOM.render(<Component/>, document.getElementById('root'));

// component.tsx
import React from 'react';
import { loggedIn } from './session';
export default function Component() {
  return loggedIn() ? <div>Ok</div> : <div>Not ok</div>;
}

// session.ts
import { makeVar } from '@apollo/client';
export const loggedIn = makeVar(false);

Due to @snowpack/plugin-react-refresh component.tsx will be hot-replaceable, but changes in session.ts should trigger full reload, which is fine for me and totally what i'd expect.

Repr steps are to first change session.ts(full page reload happens), and then change component.tsx. It will reload component.tsx, but also session.ts (both urls with ?mtime), even though session.ts was not changed again after full reload. To my understanding, dev server remembers session.ts was changed, even after full page refresh.

Reloaded component are now bound to new apollo reactive variable instances exported from session.ts?mtime=..., not interacting properly with the rest of the app.

Can i somehow configure it to not add ?mtime for modules that are not hot-replaceable?

[Xazzzi]

Digged a little further:
https://github.com/snowpackjs/snowpack/blob/main/snowpack/src/commands/dev.ts#L1175-L1196

Problem seems to be here.
hmrEngine.markEntryForReplacement(node, true); increments node.needsReplacementCount, which is then decremented on dependencies reload here: https://github.com/snowpackjs/snowpack/blob/b972763ab047d6ba73fc4308efc809a09ea39d7f/snowpack/src/commands/dev.ts#L7

It gets out of sync if full page refresh happens, ie update has a way to top which is not hot accepted.

[cherihung]

I just opened another discussion thread and then saw yours. I think I'm seeing the same thing as you. Were you able to figure it out?
#2417

[Xazzzi]

Well, i figured out the problem described it in my prev. message.
To convert it into solution is a bit too much effort for me, but general direction is:
Do not increment needsReplacementCount until entire module tree is traversed and there are no paths to root that cause full reload.

[cherihung]

thanks for the response. yeah, agree. this would be too much to make it an independent solution for each project.