Provide option to disable initial compilation when watching

[JasonTheAdams]

Do you want to request a feature or report a bug?
Feature Request

What is the current behavior?
When webpack --watch is first run, the first thing it does it compile all of the entries.

If the current behavior is a bug, please provide the steps to reproduce.

What is the expected behavior?
For webpack to simply start watching the files and not immediately compile. But given that this doesn't apply as much to single-entry instances, at least have an option for it.

If this is a feature request, what is motivation or use case for changing the behavior?
Given the number of entries (and if sourcemaps are enabled) this can can take a significant amount of time. With this feature one would be able to enable watching and immediately get to work without having to worry about whether it's finishing compiling and is actually watching, yet.

Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.
Node: 4.5.0
Webpack: 2.6.1
OS: Windows 10

[TheLarkInn]

Are you seeing bottlenecks at this point of the compilation process?

[JasonTheAdams]

Hi @TheLarkInn, only in the sense that it may take upwards of 30-60 seconds (and scaling with each entry) every time I go to start watching. Often times I'll turn it on, flip back to the code, make a couple tweaks, save, switch to the browser, refresh, and then realize that it just finished the first compilation so the changes I just made weren't included. So then I go save again, and I'm good to go. It's just was feels like an unnecessary hickup in the workflow.

[sokra]

Sounds like a bug. I should actually work this way. It compares timestamp to build start timestamp when starting watching, so this should detect changes between start of compilation and start of watching.

[kirill-konshin]

This is very much needed. Babel CLI has --skip-initial-build option for example.

My use case is a Lerna monorepo with libraries (Babelized and Webpacked) and demos, I need to build all libs as phase 1 and then run demos + watch on phase 2, so the more libs you have the more inefficient it becomes. Currently the watch procedure looks like this:

{
  "scripts": {
    "build": "lerna run build --scope=@xxx/lib-* --concurrency=1 --stream",
    "start": "npm run build && lerna run start --parallel"
  }
}

Since Lerna's --parallel completely disregards topology this phased approach is a must, demos are independent of each other while libs have dependencies on each other and demos depend on libs.

[blixt]

I have a use case where I want, inside a Makefile, to build once, then run a bash script, then start watching. Right now the watch will kick off an unnecessary build.

[alshdavid]

I have created this PR which adds:
#9735

module.exports = {
  // ...
  watchOptions: {
    skipInitialEmit: false
  }
}

[alexander-akait]

@alshdavid duplicate #9730 ?

[alshdavid]

@evilebottnawi, any chance you've had a chance to review the PR?

[kirill-konshin]

#9730 is a duplicate dated Sep 24. This one here seems to be the original issue from 2017.

[meszaros-lajos-gyorgy]

So it's been over 3 years now since the first report. Any update on this?

[sokra]

The persistent cache in webpack 5 is basically that. Instead of compiling all modules it restores them from the cache, only builds changes and watches the files.

[alshdavid]

How would this impact developers running several webpack instances, where the output of one is required as an input for the other?

[alexander-akait]

@alshdavid It is side of your code, you need run first compilation, then run second, you can run them in the same time

[meszaros-lajos-gyorgy]

My personal reason why I would love to have this feature is that in my current project I run the hosting and the building of the code parallel and cannot make the hosting wait for the first build to happen. So currently the hosting script will start running the old code, then do a live reload after a few seconds when webpack is done with the initial build. I would love to change this to only start the building first, then start the hosting and watching for changes later.

I've looked at solutions, which try to leach onto webpack's build events, but either the repos are no longer maintained (you get errors in the console because of that) or you have to add this logic into webpack config. With this addition it could all be done within the scripts of package.json.

[alexander-akait]

With this addition it could all be done within the scripts of package.json.

Is the best solution

[alshdavid]

I have been using wait-on, concurrently in combination with webpack to achieve this. You can add http-server or similar to handle serving content

{
  "name": "@org/project-root",
  "private": true,
  "workspace": [
    "./packages"
  ],
  "scripts": {
    "start": "npm run clean && npx concurrently \"npm run watch:a\" \"npm run wait:a && npm run watch:b\" \"npm run wait:b && npm run serve:b\"",
    "clean": "npm run clean:a && npm run clean:b",
    "clean:a": "rm -r -f ./packages/a/dist",
    "clean:b": "rm -r -f ./packages/b/dist",
    "wait:a": "npx wait-on packages/a/dist/index.js",
    "wait:b": "npx wait-on packages/b/dist/index.js",
    "watch:a": "cd packages/a && npx webpack --watch",
    "watch:b": "cd packages/b && npx webpack --watch",
    "serve:b": "cd packages/b/dist && npx http-server ."
  },
  "devDependencies": {
    "concurrently": "*",
    "webpack": "*",
    "http-server": "*",
    "wait-on": "*"
  }
}

[meszaros-lajos-gyorgy]

My current setup is similar, though I use npm-run-all instead of concurrently:

"scripts": {
    "dev": "cross-env NODE_ENV=development npm-run-all --parallel build:watch app:watch",
    "app:watch": "nodemon dist/server/js/server.min.js --watch dist -e js,ejs,json,css",
    "build:watch": "webpack --watch"
  }

http-server is good for serving static files, but it's not enough for me, since I have a rest api + db running in the backend.

As I see wait-on relies on watching the directory and waiting for the given file to pop into existence, which requires you to remove previously generated files before starting a new server. It's a nice solution, which I'll definitely give a try, though I feel the cleanup to be an extra step, which could be skipped using the feature request in this ticket.

[alexander-akait]

It is good solutions 👍 I don't think it is our side how you will run compilations, because we don't know about it nothing

[webpack-bot]

This issue had no activity for at least three months.

It's subject to automatic issue closing if there is no activity in the next 15 days.

[meszaros-lajos-gyorgy]

This issue had no activity for at least three months.

It's subject to automatic issue closing if there is no activity in the next 15 days.

okay, then: bump

Did anyone find any solutions or even alternatives for this?

[alexander-akait]

Answer here #9730 (comment), we can't skip otherwise we can't track your deps, but if you want to improve initial start you can use https://webpack.js.org/configuration/other-options/#cachetype with the filesystem value.

But I think the better way to solve this is to avoid emitting assets if it matches the file on disk. This won't require a flag and will speed up all builds when assets already exist.

We done it for webpack v5 (https://github.com/webpack/webpack/blob/master/lib/Compiler.js#L709)