--watch not working after updateing from webpack 4 to 5
Asked Answered
S

0

7

I have been migrating a project from Webpack 4 up to 5 and have hit a snag. The --watch option is no longer working with my configuration, and I've tried everything I can find.

const webpack = require('webpack');
const path = require('path');

const PATHS = {
  build: path.join(__dirname, "dist")
}

const baseConfig = {
  entry: {
    main: './js/router.js',
  },
  output: {
    path: PATHS.build,
    filename: `[name].[chunkhash].js`,
    chunkFilename:`[name].[chunkhash].js`,
    publicPath: '/dist'
  }
  //loaders and stuff
}

module.exports = baseConfig;

webpack --watch --progress --mode development

This is what the config can be boiled down to cause the issue. Webpack builds initially fine and I can view the page locally. enter image description here

But any further changes to the entry point or any modules it imports does not recompile. The progress option I added to the start command has no effect.

I suspect the issue lies with WSL. When I upgraded to webpack 5, I encountered this issue For some reason webpack 5 tries to scan system files if it is located in /mnt/c and gets locking errors. I ended up settling on this answer and moving where my project was located from /mnt/c/dev to /usr/local/dev. This solved the locking issue, and here I am now.

I have also tried adding to my webpack config:

watchOptions: {
    poll: true
}

and also tried playing around with different polling times. Nothing gave me different results.

Sovran answered 13/5, 2021 at 17:54 Comment(3)
WSL1 or WSL2? WSL2 should not have worked on /mnt/c/dev, but should work on /usr/local/dev (see this related answer for more details). Although, polling should work around the issue, so I'm just not sure what you're facing. Also, just a side-note, you might think "/usr" stands for "user", but it actually is an abbreviation for "unix system resources". IMHO, it is really not the place to store project files. Those should be in something like $HOME/src or something.Putup
I am on WSL 1, I have heard mixed things about 2 and didn't want to update. I'm kind of out of troubleshooting ideas at this point. I did have this misconception about the usr dir, thank you. I once googled what location would be best practice to put various scripts or server deployments and I remember /usr/local being recommended.Sovran
Agreed - With your use case, WSL1 is probably the better fit. WSL1 and WSL2 both have their benefits and drawbacks, so I keep both around. I'll noodle on the --watch issue -- I just haven't come across any questions like that so far on WSL1, and no ideas pop to mind immediately. Re: usr -- I've been using Linux casually for a couple of decades and I always thought that naming was strange, also mentally pronouncing it "user", but knowing it contained system files. Only recently did I come across a mention of it being an acronym myself.Putup

© 2022 - 2024 — McMap. All rights reserved.