naturalcrit / homebrewery

Create authentic looking D&D homebrews using only markdown
https://homebrewery.naturalcrit.com
MIT License
1.08k stars 326 forks source link

LESS files are not rebuilt on saved changes #2909

Open Gazook89 opened 1 year ago

Gazook89 commented 1 year ago

Renderer

v3

Browser

Chrome

Operating System

MacOS

What happened?

When making changes to LESS files in the repo, and saving the file, the server is reloaded but the /build/ files are not updated. The server has to be stopped and go through the build process again before the changes get pushed through.

I can't find the issue in buildHomebrew.js after looking through Nodemon and Vitreum docs/readme. I've run npm install and npm update.

At this point I'd like to just confirm that others have this issue? I got a new mac with silicon chip and while i've assumed that isn't the issue (I have no idea why it would be) I guess it'd just feel good to confirm that, too.

This will basically be enough for me to avoid trying to create themes in the meantime (not that I was really laying them on thick to begin with...)

Code

No response

G-Ambatte commented 1 year ago

I'm getting a rebuild (on Windows 10 x64) when making changes to /shared/naturalcrit/nav/nav.less (specifically, commenting out the nav .navDropdownContainer .navDropdown .navItem:vertical-align property, as VSCode flags that property as ignored due to display setting).

Commented: image

Uncommented: image

Maybe it's the specific LESS file - which one are you changing?

Gazook89 commented 1 year ago

The styles.less files in themes

calculuschild commented 1 year ago

Ok, I haven't touched this for a while, but looks like we may need to again tweak this script, because we actually have not 1 but 3 code monitoring pieces here that I didn't fully understand before:

1) Nodemon - This is the watchFile function at the bottom. Monitors those directories for changes, and if found, it will restart the server. This is useful when editing backend server files. 2) LiveReload - This is the livereload function at the bottom. Monitors that directory for changes, and if found, it interacts with an old Chrome Extension to refresh the browser page. This extension doesn't work anymore, so this line is useless. 3) Watchify - This is the dev : isDev && build, line, and is a Browserify plugin (our code bundler). This monitors any source file mentioned in paths: or included by the first argument to pack ('./client/homebrew/homebrew.jsx'). When it detects a change, it re-bundles './client/homebrew/homebrew.jsx', then runs sends those bundles to the function listed in the dev : property, which is build().

So, in build(), we actually output the files from the re-bundled code, so that covers most .less files if they are associated with the larger bundle.css file (nav.less is part of that bundle because it gets include'd by something else in the bundle). But all the separate files (themes CSS, etc.) we are handling outside of the build() function. Sooo.... it's probably just a matter of pulling those steps (everything under the compile themes comment) out of their anonymous async function and inserting them into build() at the right place (probably just at the end).

Also note, as for LiveReload not working anymore, there is a very similar Chrome extension at Live Reload which actually works (I tested it), but instead of connecting to your server to detect changes, you just give it a path to the files you want it to monitor. In this case, just set up the extension to look for all source files: image

Gazook89 commented 1 year ago

Okay, that pretty much confirms what I had figured out last night, but I wasn’t sure enough to say “pretty sure this stuff is wack right now”. I sort of assumed I was not really understanding it at all.

G-Ambatte commented 1 year ago

OK, I think I understand how it works now. Long story short, if we shuffle lines 48 through 100 of the current script up a few lines so that they're inside the build function, then they will get executed every time a change is detected.

Unrelated to this particular change, I suspect that bringing the building of the /admin pages into the main buildHomebrew.js script would probably need to happen in a similar fashion.