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

bud dev not watch blade.php files #1004

Closed
lorenzofranzone-it opened this issue Jan 20, 2022 · 10 comments · Fixed by #1007
Closed

bud dev not watch blade.php files #1004

lorenzofranzone-it opened this issue Jan 20, 2022 · 10 comments · Fixed by #1007
Assignees
Labels
bug Something isn't working

Comments

@lorenzofranzone-it
Copy link

hello! after having troubles updating "bud" and "sage" I tried with a new clean test installation "roots bedrock" + "roots sage" to verify the "bud dev" command.

modifying javascript and css file the page immediately applies the changes, but if I edit a blade.php file I can see these changes only by reloading the page.

bud.config.js file setup is the original one.

also note that the tailwind-debug-screens plugin with the update is no longer shown in the "body" tag of index.php.

Has anyone had the same problem in development? thank you all.

@farmerpaul
Copy link

farmerpaul commented Jan 20, 2022

I have the same issue described above – no recompilation or reloading when a Blade file is changed. I'm seeing this after creating a fresh Sage WordPress theme today using composer create-project roots/sage dev-main, which has been updated to use Bud 5.1.0. In addition to the bud dev seeming to not respond to changes to Blade files, this also happens for me:

  • When I edit app.css (the main CSS file specified in one of the entrypoints), bud dev seems to go into an infinite loop of recompiling.
  • When I edit any local CSS file that's imported from app.css, bud dev seems to ignore those edits altogether and it doesn't trigger a recompile. Adding 'resources/styles/**/*.css' to the .watch() section of bud.config.js doesn't fix this.

Here are the relevant lines from my bud.config.js in case it's helpful:

module.exports = (app) =>
  app
    .entry({
      app: ['scripts/app.js', 'styles/app.css'],
      editor: ['scripts/editor.js', 'styles/editor.css'],
    })

    

    .watch([
      'tailwind.config.js',
      'resources/views/**/*.blade.php',
      'app/View/**/*.php',
      'resources/styles/**/*.css',
    ])

    

Apologies if this comment is better suited to be filed under roots/sage, but since I saw the issue only posted here, I thought I should stick to the relevant thread rather than create a second one.

@lorenzofranzone-it
Copy link
Author

lorenzofranzone-it commented Jan 20, 2022

  • When I edit app.css (the main CSS file specified in one of the entrypoints), bud dev seems to go into an infinite loop of recompiling.

Hi farmerpaul, for this specific case there is a good section in the official tailwindcss documentation:
https://tailwindcss.com/docs/content-configuration#styles-rebuild-in-an-infinite-loop

@farmerpaul
Copy link

Thanks @franzonelorenzo – although that page doesn't seem to be helpful for me. The infinite recompiling happens even when I don't specify any CSS files in the .watch() section of bud.config.js. This is a fresh theme from Sage, so you'd think it should just work out of the box anyway. But I get that this is all heavily beta right now. :)

@lorenzofranzone-it
Copy link
Author

Thanks @franzonelorenzo – although that page doesn't seem to be helpful for me. The infinite recompiling happens even when I don't specify any CSS files in the .watch() section of bud.config.js. This is a fresh theme from Sage, so you'd think it should just work out of the box anyway. But I get that this is all heavily beta right now. :)

yes in my case the loop problem was caused exclusively by the purge in the tailwind.config.js solved by adding all the specific files, but the list was really too long so I opted for the bedrock folder structure. :)

@kellymears kellymears added the bug Something isn't working label Jan 21, 2022
@kellymears kellymears mentioned this issue Jan 22, 2022
3 tasks
@kellymears kellymears self-assigned this Jan 22, 2022
@kellymears
Copy link
Contributor

I have a fix for this in draft. Just need to confirm it's working in an actual project and then we're good to ship it.

@davideprevosto
Copy link

davideprevosto commented Jan 22, 2022

If you'd like a one more confirm, I could try on an actual project too @kellymears

@farmerpaul
Copy link

farmerpaul commented Jan 22, 2022

@kellymears I'm trying to test your PR in my project, but I'm having trouble figuring out how best to easily pick your branch fix-watch-mode via yarn. I tried:

yarn add --dev https://github.com/roots/bud.git#fix-watch-mode

which I guess worked (there were no errors), but what it ended up doing was add the package under node_modules/bud instead of replacing the package under node_modules/@roots/bud, so now I have two bud packages installed. I guess I could manually rearrange the folders and hope that works, but I'd be curious if there's a more "correct" way to test a particular git branch of an npm dependency in an existing project.

EDIT: Looks like the directory structure under node_modules/@roots/bud is actually quite different from node_modules/bud, so it seems I'm not going about this right. I'll keep hammering away in the meantime…

EDIT 2: So I think I understand now that I need to basically set up a development environment for bud, check out the correct branch for the PR, do a yarn install, then yarn @bud build to build bud, and after that succeeds, I should eventually be able to figure out how to incorporate that build of bud into my current Sage project! Only problem now is that the yarn @bud build command fails with 13 errors, all of them of the form:

The inferred type of '<identifer>' cannot be named without a reference to 'bud/node_modules/stylelint-webpack-plugin/declarations/options'. This is likely not portable. A type annotation is necessary.

This is feeling somewhat out of my wheelhouse at this point, but I do want to help…

@retlehs
Copy link
Member

retlehs commented Jan 25, 2022

this is fixed in the upcoming 5.2.0 release, just keeping it open until the release is tagged

@lorenzofranzone-it
Copy link
Author

Thank you @retlehs !!! :)

@retlehs
Copy link
Member

retlehs commented Jan 26, 2022

v5.2.0 is out thanks to @kellymears 🎉

sage users can reference roots/sage#2959 to see what's changed from v5.1.0 to v5.2.0 in sage

@retlehs retlehs closed this as completed Jan 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants