fix(hmr): allow changes to component decorators when using HMR

[alicewriteswrongs]

This fixes an issue where HMR updates which changed arguments to the @Component decorator would crash the application because a HostRef for the component could not be located.

This occurred because HMR updates caused a new version of the component's lazy bundle to be fetched, which in turn would bundle the getHostRef function and the corresponding hostRefs variable, which is declared here:

stencil/src/client/client-host-ref.ts

Line 18 in 0041dc2

export const getHostRef = (ref: d.RuntimeRef): d.HostRef | undefined => hostRefs.get(ref);

Because the newly fetched lazy entry point for the updated component did not have access to the hostRefs variable which was in-scope in the old bundle, the getHostRef function would always return undefined on the first render after the HMR update, causing issues in functions like setValue which make use of a HostRef.

In order to fix the issue we can persist the hostRefs map across HMR updates by storing a reference to it on the window object. We can additionally constrain this persistence to only occur when we're building with HMR, so that we don't clutter up the window object of unsuspecting Stencil users in the context of a production build.

What is the current behavior?

Unfortunately at present if you are using the hot-reload dev server and you make an edit to the @Component decorator of your component you'll see a big error in the browser console, and you'll be forced to reload 😢. The error will look something like this:

Not such a nice time.

What is the new behavior?

Now if you make an edit to your @Component decorator you'll just see your component get updated in the browser with no errors.

Does this introduce a breaking change?

• Yes
• No

Testing

In order to test this I would recommend the following:

• confirm that you can reproduce the issue
  • create a new project with

    cd /tmp && \
    npm init stencil@latest component hmr-issue && \
    cd hmr-issue && \
    npm install

  • then confirm that if you start the dev server (npm start) and edit a property in @Component you see an error in the console like above
• then confirm the fix
  • build and pack this branch:

    cd /tmp && \
    git clone git@github.com:ionic-team/stencil.git && \
    cd /tmp/stencil && \
    git checkout ap/allow-component-decorator-hmr && \
    npm install && \
    npm run install.jest && \
    npm run build && \
    npm pack

  • install into the sample project:

    cd /tmp/hmr-issue && \
    npm i ../stencil/stencil-core-4.11.0.tgz

  • then, as above, start the dev server (npm start) and confirm that editing the @Component decorator doesn't cause catastrophic issues anymore

[github-actions]

--strictNullChecks error report

Typechecking with --strictNullChecks resulted in 1209 errors on this branch.

That's the same number of errors on main, so at least we're not creating new ones!

reports and statistics

Our most error-prone files

Path	Error Count
src/dev-server/index.ts	37
src/mock-doc/serialize-node.ts	36
src/dev-server/server-process.ts	32
src/compiler/prerender/prerender-main.ts	22
src/testing/puppeteer/puppeteer-element.ts	22
src/runtime/client-hydrate.ts	20
src/screenshot/connector-base.ts	19
src/runtime/vdom/vdom-render.ts	17
src/compiler/config/test/validate-paths.spec.ts	16
src/dev-server/request-handler.ts	15
src/compiler/prerender/prerender-optimize.ts	14
src/compiler/sys/stencil-sys.ts	14
src/compiler/transpile/transpile-module.ts	14
src/sys/node/node-sys.ts	14
src/compiler/prerender/prerender-queue.ts	13
src/compiler/sys/in-memory-fs.ts	13
src/runtime/connected-callback.ts	13
src/runtime/set-value.ts	13
src/compiler/output-targets/output-www.ts	12
src/compiler/transformers/test/parse-vdom.spec.ts	12

Our most common errors

Typescript Error Code	Count
TS2345	366
TS2322	362
TS18048	224
TS18047	99
TS2722	37
TS2532	26
TS2531	23
TS2454	14
TS2352	12
TS2790	11
TS2769	8
TS2538	8
TS2344	6
TS2416	6
TS2493	3
TS18046	2
TS2684	1
TS2430	1

Unused exports report

There are 14 unused exports on this PR. That's the same number of errors on main, so at least we're not creating new ones!

Unused exports

File	Line	Identifier
src/runtime/bootstrap-lazy.ts	21	setNonce
src/screenshot/screenshot-fs.ts	18	readScreenshotData
src/testing/testing-utils.ts	198	withSilentWarn
src/utils/index.ts	145	CUSTOM
src/utils/index.ts	269	normalize
src/utils/index.ts	7	escapeRegExpSpecialCharacters
src/compiler/app-core/app-data.ts	25	BUILD
src/compiler/app-core/app-data.ts	115	Env
src/compiler/app-core/app-data.ts	117	NAMESPACE
src/compiler/fs-watch/fs-watch-rebuild.ts	123	updateCacheFromRebuild
src/compiler/types/validate-primary-package-output-target.ts	61	satisfies
src/compiler/types/validate-primary-package-output-target.ts	61	Record
src/testing/puppeteer/puppeteer-declarations.ts	485	WaitForEventOptions
src/compiler/sys/fetch/write-fetch-success.ts	7	writeFetchSuccessSync

[christian-bromann]

I can successfully reproduce the fix. The only nit I have is the any cast of the window object. I am not sure how types are set up, if it requires to many changes we can keep as is.

👍

[rwaskiewicz]

LGTM! Found another related bug when I was testing this, but I think it's outside of the scope of what we're looking to do here. Captured details in STENCIL-1113