WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.35k stars 4.13k forks source link

Scripts: npm run start does not load refreshed stylesheet into editor-canvas iframe, only head of main document #48448

Open helgatheviking opened 1 year ago

helgatheviking commented 1 year ago

What problem does this address?

I created an example block plugin via npx @wordpress/scripts create-block then I changed into the new directory and ran npm run start

I added my new sample block into the editor to start playing around with it. And I noticed that the text was illegible due to inaccessible colors (dark gray text on a gray blue background) image

I made a change to src/style.scss and the stylesheet was re-compiled.

But when I refreshed the editor page, nothing happened. In source the stylesheet still has a version of 0.1 which appears to be the style set in block.json as there's no enqueue_block_editor_assets anywhere to enqueue assets. Updating the version in block.json finally forces the browser to refresh the stylesheet.

If that's intended behavior it's very counter to what I think npm run start is meant to do... put you in a developmental mode where everything updates as soon as you make a change..... even more so if you are attempting npm run start --hot and expecting hot reloading.

What is your proposed solution?

npm run start should enqueue a stylesheet based on the time it was last compiled... which I believe can already be found in build/index.asset.php and I as far as I can tell is used for the javascript files (as a change in src/edit.js) is immediately shown in the editor.

github-actions[bot] commented 1 year ago

Hi, This issue has gone 30 days without any activity. This means it is time for a check-in to make sure it is still relevant. If you are still experiencing this issue with the latest versions, you can help the project by responding to confirm the problem and by providing any updated reproduction steps. Thanks for helping out.

tomfinitely commented 1 year ago

+1

Supportic commented 1 year ago

If you run npm run start it will just rebuild your assets which means... In the frontend you see the changes after reload because the styles are injected in <style> tags which immediately reflects the changes. In the backend however it calls your style.css file with your version from block.json attached to it. http://localhost/app/plugins/<pluginName>/build/accordion/index.css?ver=0.3.0 If you are not familiar with cache busting: the browser caches the file for you unless you hard reload (CTRL+SHIFT+R) or keep devtools open with the (no cache) option selected and normal reload. As soon as you change the block version the URL of this file changes and the browser thinks that this must be a new file because it looks different than before index.css?ver=0.3.1.

There are 2 other more developer friendly option you could implement which is: 1) your own webpack.config.js file where you define the output files with a unique contenthash included (see https://webpack.js.org/guides/caching/) or 2) use browsersync which reloads the page after file change through websockets with the new information.

This might help https://github.com/WordPress/gutenberg/pull/28273

github-actions[bot] commented 1 year ago

Hi, This issue has gone 30 days without any activity. This means it is time for a check-in to make sure it is still relevant. If you are still experiencing this issue with the latest versions, you can help the project by responding to confirm the problem and by providing any updated reproduction steps. Thanks for helping out.

ndiego commented 1 year ago

As @Supportic mentioned above, you will need to clear the cache occasionally or follow one of the suggestions posted above. I personally use create-block all the time and just get in the habit of periodically clearing the cache.

I am going to close out this issue, but please feel free to reopen if you are experiencing any additional issues.

helgatheviking commented 1 year ago

The frontend styles/scripts regenerate a version number on every file change (via the assets PHP file) which automatically busts the cache. The admin should have the same. It's a pain to clear the cache while developing the admin side. Please consider reopening.

ndiego commented 1 year ago

@helgatheviking of course, happy to reopen.

gorm commented 7 months ago

To me it looks it's already loading style-index.css with a timestamp when index.scss is edited, so the caching should not be an issue and it's not caused by lack of version change.

The real issue here seems to be that it's loading the style-index.css?<timestamp> into the main document and not into the editor iframe document so it's never replacing the initial style loaded with the version from block.json.

Might be caused by not externalizing react-refresh. It's mentioned the troubleshooting there and it's also some more information in this issue.

gziolo commented 7 months ago

Might be caused by not externalizing react-refresh.

It is externalized. That's necessary for making it work with the way WordPress enqueues scripts.

The real issue here seems to be that it's loading the style-index.css? into the main document and not into the editor iframe document so it's never replacing the initial style loaded with the version from block.json.

That sounds very likely to happen. I would recommend exploring that path further 👍

gorm commented 7 months ago

Yea, I debugged it in the inspector yesterday and observed that everything worked and change of index.scss trigged a full css reload, except I found the newly loaded correct style in the of the document and the initial loaded style was still there in the iframe. So pretty sure this is the issue.

gorm commented 7 months ago

It is externalized. That's necessary for making it work with the way WordPress enqueues scripts.

Maybe a result of the externalization then? https://github.com/pmmmwh/react-refresh-webpack-plugin/issues/743

helgatheviking commented 7 months ago

Just ran into this issue again a year later. Is there anything I can do to nudge this along. I'm new to block dev, and having to clear the cache on my browser (which logs me out of my dev site) in order to test changes to editor styles is a very annoying barrier.

gorm commented 7 months ago

I looked a bit more into the issue, but couldn't find a way around it. Seems rather tricky. Think wp-scripts need to have an insert function for mini-css-extract-plugin that adds the linkTag both to the iframe and the head of the document.

But the insert function doesn't run because it can't find the chunkId and there are even testcases on mini-css-extract-plugin with this behavior. Might be a red herring, but because of this I couldn't get the insert function to run.

Could also be possible to just have a hack in your plugin that clones the link tags. I'm sure some block developers have fixed this somehow already as everyone developing using create-block can't be sitting reloading the page all the time, I hope 😕

Would also be good if someone changed the title of this bug. Should be something like: "npm run start does not load refreshed stylesheet into editor-canvas iframe, only head of main document"