Closed Erutan409 closed 7 months ago
sure np, thanx
@ctf0 I need more time to work on it. The webpack build needs to complete before any subsequent modifications should occur (combine). So, I'm going to abstract it out a little further so that it's not complicated to support.
can u tell me more of what is the issue exactly ?
If you register the plugin, but don't invoke the register method, you'll see the error. And it's because of the way that the method for hashing files outside of the webpack context are handled/triggered. It's an invocation order issue. So, what I'm trying to do now is abstract out the proxying a little more, so it's more like a promise, while detecting if the plugin was actually used.
When Laravel Mix loads the plugin with .extend()
, it's invoking the plugin's constructor, which binds the functionality for hashing the combined assets. But, that doesn't mean the plugin is actually being used. So, the options config (which is created when actually invoking the plugin), isn't being set on the this
context of the instance. And causing errors with the new combine hashing functionality.
I think I ran into this very issue. However, I could not detect which plugin is being registered but not used as of this writing. The only current fix for my problem has been completely disabling mix.versionHash()
from my webpack.config.js
EDIT: btw, I was pulling my hair out last night since this error suddently showed up OUT OF NOWHERE (no npm update
nor npm install
ran).
EDIT 2: loading versionhash only in production currently did the trick for npm run dev
if (mix.inProduction()) {
// FIXME: something is wrong for me to need to disable this package
require('laravel-mix-versionhash')
// FIXME: There is something wrong with this
mix.versionHash()
} else {
mix.sourceMaps()
}
@Erutan409 any news ?
@ctf0 Seems like there may have been an issue introduced with various refactoring since my last PR. I'm going to push a fix in an hour or two and submit the PR.