Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[bug] assets not compiling + hmr not working in dev after 6.18.0 #2529

Closed
3 tasks done
mr-moto opened this issue Dec 18, 2023 · 9 comments · Fixed by #2530
Closed
3 tasks done

[bug] assets not compiling + hmr not working in dev after 6.18.0 #2529

mr-moto opened this issue Dec 18, 2023 · 9 comments · Fixed by #2530
Labels
question Further information is requested

Comments

@mr-moto
Copy link

mr-moto commented Dec 18, 2023

Agreement

Describe the issue

When upgrading to 6.18.0+, hmr stops working and assets dont compile properly on the dev server.
running build will compile assets and show correctly but as soon as the dev server is run those changes are lost.

running a fresh install of sage. 6.17.0 works perfectly. checking if hmr is working by changing some tailwind css.

Expected Behavior

  • HMR should work when assets are changed
  • assets should compile when running the dev server

Actual Behavior

  • HMR does not work
  • assets do not compile
  • seems to revert back to a cached version when running the dev server (?)

Steps To Reproduce

  1. fresh install of sage theme
  2. install 6.18.0 || 6.19.0 || 6.19.1 of bud
  3. run the dev server
  4. add/edit some tailwind styles

version

6.18.0

Logs

No response

Configuration

No response

Relevant .budfiles

/**
 * Compiler configuration
 *
 * @see {@link https://roots.io/docs/sage sage documentation}
 * @see {@link https://bud.js.org/guides/configure bud.js configuration guide}
 *
 * @type {import('@roots/bud').Config}
 */
export default async (app) => {
  /**
   * Application assets & entrypoints
   *
   * @see {@link https://bud.js.org/docs/bud.entry}
   * @see {@link https://bud.js.org/docs/bud.assets}
   */
  app
    .entry('app', ['@scripts/app', '@styles/app'])
    .entry('editor', ['@scripts/editor', '@styles/editor'])
    .assets(['images']);

  /**
   * Set public path
   *
   * @see {@link https://bud.js.org/docs/bud.setPublicPath}
   */
  app.setPublicPath('/app/themes/sage/public/');

  /**
   * Development server settings
   *
   * @see {@link https://bud.js.org/docs/bud.setUrl}
   * @see {@link https://bud.js.org/docs/bud.setProxyUrl}
   * @see {@link https://bud.js.org/docs/bud.watch}
   */
  app
    .setUrl('http://localhost:3000')
    .setProxyUrl('http://smart-tek.local')
    .watch(['resources/views', 'app']);

  /**
   * Generate WordPress `theme.json`
   *
   * @note This overwrites `theme.json` on every build.
   *
   * @see {@link https://bud.js.org/extensions/sage/theme.json}
   * @see {@link https://developer.wordpress.org/block-editor/how-to-guides/themes/theme-json}
   */
  app.wpjson
    .setSettings({
      color: {
        custom: false,
        customDuotone: false,
        customGradient: false,
        defaultDuotone: false,
        defaultGradients: false,
        defaultPalette: false,
        duotone: [],
      },
      custom: {
        spacing: {},
        typography: {
          'font-size': {},
          'line-height': {},
        },
      },
      spacing: {
        padding: true,
        units: ['px', '%', 'em', 'rem', 'vw', 'vh'],
      },
      typography: {
        customFontSize: false,
      },
    })
    .useTailwindColors()
    .useTailwindFontFamily()
    .useTailwindFontSize();
};
@mr-moto mr-moto added the bug Something isn't working label Dec 18, 2023
@kellymears
Copy link
Member

Are you using Local by Flywheel with Windows? If so, are you running it outside of WSL2? bud.js does not support Windows outside of WSL2.

It's kind of awesome that 6.17.x worked with Windows natively, but it was an accident.

@kellymears kellymears added question Further information is requested and removed bug Something isn't working labels Dec 18, 2023
@mr-moto
Copy link
Author

mr-moto commented Dec 18, 2023

@kellymears Im on an m2 mac, but yea im using Local 🙂

@kellymears
Copy link
Member

kellymears commented Dec 18, 2023

@mr-moto this is my experience:

bud-6.19.1.mov

Modified lines in bud.config.js:

  app.setPublicPath('/wp-content/themes/sage/public/');

  app
    .setUrl('http://localhost:3000')
    .setPublicUrl('http://flywheel.local:3000')
    .setProxyUrl('http://flywheel.local')
    .watch(['resources/views', 'app']);

project manifest:

{
  "devDependencies": {
    "@roots/bud": "6.19.1",
    "@roots/bud-tailwindcss": "6.19.1",
    "@roots/sage": "6.19.1"
  }
}

I didn't have Local installed prior to the bug reports in >=6.19.0, but I set it up on Friday to see what was going on. Everything seems like it works, so I'm kind of stumped at the moment.

@kellymears
Copy link
Member

When I set it up I was also under the mistaken impression that Local ran in a Docker container.. it doesn't.

So, this simpler setup works as well:

  app
    .setUrl('http://localhost:3000')
    .setProxyUrl('http://flywheel.local')

@mr-moto
Copy link
Author

mr-moto commented Dec 18, 2023

ok interesting, so it seems as though hmr works when running the dev server through their provided shell. It doesnt work when running the dev server outside of it.. At least its working, any clue as to why that might be?

Thanks for pointing me in the right direction!

@mr-moto mr-moto closed this as completed Dec 18, 2023
@kellymears
Copy link
Member

I had no idea that was even what was going on until your diagnosis, so thanks to you!

The shell script that gets invoked by Local is not much help; I don't see anything special here:

export DISABLE_AUTO_TITLE="true"
echo -n -e "\033]0;flywheel Shell\007"

export MYSQL_HOME="[App Support]/Local/run/_QPdg9vDh/conf/mysql"
export PHPRC="[App Support]/Local/run/_QPdg9vDh/conf/php"
export WP_CLI_CONFIG_PATH="/Applications/Local.app/Contents/Resources/extraResources/bin/wp-cli/config.yaml"
export WP_CLI_DISABLE_AUTO_CHECK_UPDATE=1

# Add PHP, MySQL, and WP-CLI to $PATH
echo "Setting Local environment variables..."

export PATH="[App Support]/Local/lightning-services/mysql-8.0.16+6/bin/darwin/bin:$PATH"
export PATH="[App Support]/Local/lightning-services/php-8.1.23+0/bin/darwin-arm64/bin:$PATH"
export PATH="/Applications/Local.app/Contents/Resources/extraResources/bin/wp-cli/posix:$PATH"
export PATH="/Applications/Local.app/Contents/Resources/extraResources/bin/composer/posix:$PATH"


export MAGICK_CODER_MODULE_PATH="[App Support]/Local/lightning-services/php-8.1.23+0/bin/darwin-arm64/ImageMagick/modules-Q16/coders"


echo "----"
echo "WP-CLI:   $(wp --version)"
echo "Composer: $(composer --version | cut -f3-4 -d" ")"
echo "PHP:      $(php -r "echo PHP_VERSION;")"
echo "MySQL:    $(mysql --version)"
echo "----"

cd "[Project Dir]/app/public"


echo "Launching shell: $SHELL ..."
exec $SHELL

@kellymears
Copy link
Member

Question: does running it in your normal terminal now work? It does for me.

I had installed Local@8.0.0 and was trying to test it with that version and now it works when initiating the shell from Flywheel or from a normal session. I don't know if that's the result of having both versions in ~/Applications or the result of something else.

It would be nice if I were just trying to develop a site, but I'm trying to troubleshoot something so it's annoying to not be able to replicate the behavior anymore 😂. Flywheel only releasing binary is not helpful either, obviously.

As an aside, these settings work for me with the Flywheel generated SSL certificate:

  app
    .serve({
      cert: `/Users/kellymears/Library/Application\ Support/Local/run/router/nginx/certs/flywheel.local.crt`,
      key: `/Users/kellymears/Library/Application\ Support/Local/run/router/nginx/certs/flywheel.local.key`,
    })
    .setPublicUrl(`https://flywheel.local:3000`)
    .setProxyUrl('https://flywheel.local')

Which is very nice to have:

image

@retlehs: this issue is likely relevant to various support requests

@mr-moto
Copy link
Author

mr-moto commented Dec 19, 2023

@kellymears still not working in my normal terminal :(

for what its worth, the wp-react-refresh-runtime dependency is being used out side of the shell. not sure if it has anything to do with it.

you can see it being used/not used in /public/entrypoints.json depending on if it was run from the Local shell or not

@kellymears
Copy link
Member

@mr-moto that was a super helpful observation, thank you!

kodiakhq bot pushed a commit that referenced this issue Dec 20, 2023
This fixes #2529 and other associated problems with hot module reload in certain WordPress environments.

## The problem

If `SCRIPT_DEBUG` is not set and a script declares `wp-react-refresh-runtime` as a dependency, WordPress will _**silently** omit the entire enqueue request_.

What the... 🙈

Bedrock installs don't trigger this behavior because Bedrock defines it:

https://github.com/roots/bedrock/blob/master/config/environments/development.php#L14

## Solution

This change omits including `wp-react-refresh-runtime` in `entrypoints.json` and does not externalize `react-refresh/runtime.js` if `SCRIPT_DEBUG` isn't set in a .env file somewhere.

## Type of change

**PATCH: backwards compatible change**
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants