When changing bundle-text imported css there is no hot styling reloading happening

[danieltroger]

🐛 bug report

1. Download attached .zip
2. npm install
3. npm run serve
4. Use tampermonkey/devtools/a chrome extension to inject a script with src http://localhost:1234/main.js into a page.
5. Edit src/my.css

-> nothing happens

🎛 Configuration (.babelrc, package.json, cli command)

See .zip file

🤔 Expected Behavior

Either somehow the code inserting the styling magically gets reran or the page just reloaded.

😯 Current Behavior

Some code for bundling style assets with a HTML page is ran and removes and re-adds all elements to the page but it doesn't help - nothing happens

💁 Possible Solution

Simplest solutions is to just reload the page, the same that happens if you edit src/main.ts

🔦 Context

Have script with bundle-text'ed css, need to manually reload each time.

💻 Code Sample

parcel-no-bundle-text-css-hmr.zip

🌍 Your Environment

Software	Version(s)
Parcel	2.0.0-nightly.729+e63235f3
Node	v16.3.0
npm/Yarn	npm 7.15.1
Operating System	macOS 10.15.7 (19H1217)

[mischnic]

Ideally, import css from "bundle-text:./my.css"; should be have like a regular JS import, so any change in my.css or its dependencies should trigger an HMR update that can be caught with module.hot.accept or bubble up to the root, causing a browser refresh.

This way, you could in theory still have it update without a page reload by setting style.textContent upon an update (either manually or by creating plugin to automate that)

[danieltroger]

Yo this issue still persists and it seems to have gotten worse? Previously some parts of my JS were still re-executed when I saved the CSS so I could trigger a pageload from there, but now it seems to do nothing except clearing the console.

I just found https://parceljs.org/features/development/#hot-reloading and there it says

By default, Parcel fully reloads the page, but in some cases it may perform Hot Module Replacement (HMR).

But I don't do any module.hot stuff and it doesn't reload.

I just tried doing the module.hot.accept() thing and it didn't trigger on the CSS :(

Unrelated: I've been trying some react stuff and I occassionally got Uncaught TypeError: can't access property "prevExports", module.hot.data is undefined but couldn't figure out how to reproduce it :( I convinced my colleagues to switch the react repo to parcel and they'll for sure think parcel is unfinished software and I can't be trusted when they run into that bug. Soooo if it rings any bells pls lmk.

[whaaaley]

Yeah same issue here. As a stop-gap Is there any way to keep old school reloading but disable HMR?

[whaaaley]

the module.hot stuff in the documentation doesn't trigger at all when css is changed, however, lucky for me the dom still mutates and is updated with a new uid on the css url. here's a quick hack that'll reload when the head changes. it'll work for now but there really does need to be a way to just force reloads imo.

let index = 0

const observer = new MutationObserver(function () {
  if (index++ > 2) {
    window.location.reload()
  }
})

observer.observe(document.head, { childList: true })

[sebastianomorando]

I have the same problem here, I'm trying to have a custom html component with is shadow dom, and I wanted to import the css as text to attach him to the shadow root as as a style tag, but it fails to reload whenever i edit the css files imported as a bundle-text

[LoganDark]

When I do:

import css from 'bundle-text:./style.scss'

and then change style.scss - nothing happens. (Parcel rebuilds the module and then proceeds to do exactly nothing with it.)

if I change style.scss and then update the module that imports it - that module is reloaded with a new one that still includes the old value for css anyway (even if Parcel has already finished building a newer version).

When I do:

const css = await import('bundle-text:./style.scss')

css is an empty object ({}).

Parcel makes it impossible to hot-reload CSS by not only failing to update dependents, but even if dependents are manually updated, using a perma-cached string anyway.

Passing --no-cache to the CLI doesn't fix this.

Surely this is not intended. @mischnic