Giter Club home page Giter Club logo

watchpack's Introduction

watchpack

Wrapper library for directory and file watching.

Test Codecov Downloads

Concept

watchpack high level API doesn't map directly to watchers. Instead a three level architecture ensures that for each directory only a single watcher exists.

  • The high level API requests DirectoryWatchers from a WatcherManager, which ensures that only a single DirectoryWatcher per directory is created.
  • A user-faced Watcher can be obtained from a DirectoryWatcher and provides a filtered view on the DirectoryWatcher.
  • Reference-counting is used on the DirectoryWatcher and Watcher to decide when to close them.
  • The real watchers are created by the DirectoryWatcher.
  • Files are never watched directly. This should keep the watcher count low.
  • Watching can be started in the past. This way watching can start after file reading.
  • Symlinks are not followed, instead the symlink is watched.

API

var Watchpack = require("watchpack");

var wp = new Watchpack({
	// options:
	aggregateTimeout: 1000,
	// fire "aggregated" event when after a change for 1000ms no additional change occurred
	// aggregated defaults to undefined, which doesn't fire an "aggregated" event

	poll: true,
	// poll: true - use polling with the default interval
	// poll: 10000 - use polling with an interval of 10s
	// poll defaults to undefined, which prefer native watching methods
	// Note: enable polling when watching on a network path
	// When WATCHPACK_POLLING environment variable is set it will override this option

	followSymlinks: true,
	// true: follows symlinks and watches symlinks and real files
	//   (This makes sense when symlinks has not been resolved yet, comes with a performance hit)
	// false (default): watches only specified item they may be real files or symlinks
	//   (This makes sense when symlinks has already been resolved)

	ignored: "**/.git"
	// ignored: "string" - a glob pattern for files or folders that should not be watched
	// ignored: ["string", "string"] - multiple glob patterns that should be ignored
	// ignored: /regexp/ - a regular expression for files or folders that should not be watched
	// ignored: (entry) => boolean - an arbitrary function which must return truthy to ignore an entry
	// For all cases expect the arbitrary function the path will have path separator normalized to '/'.
	// All subdirectories are ignored too
});

// Watchpack.prototype.watch({
//   files: Iterable<string>,
//   directories: Iterable<string>,
//   missing: Iterable<string>,
//   startTime?: number
// })
wp.watch({
	files: listOfFiles,
	directories: listOfDirectories,
	missing: listOfNotExistingItems,
	startTime: Date.now() - 10000
});
// starts watching these files and directories
// calling this again will override the files and directories
// files: can be files or directories, for files: content and existence changes are tracked
//        for directories: only existence and timestamp changes are tracked
// directories: only directories, directory content (and content of children, ...) and
//              existence changes are tracked.
//              assumed to exist, when directory is not found without further information a remove event is emitted
// missing: can be files or directorees,
//          only existence changes are tracked
//          expected to not exist, no remove event is emitted when not found initially
// files and directories are assumed to exist, when they are not found without further information a remove event is emitted
// missing is assumed to not exist and no remove event is emitted

wp.on("change", function(filePath, mtime, explanation) {
	// filePath: the changed file
	// mtime: last modified time for the changed file
	// explanation: textual information how this change was detected
});

wp.on("remove", function(filePath, explanation) {
	// filePath: the removed file or directory
	// explanation: textual information how this change was detected
});

wp.on("aggregated", function(changes, removals) {
	// changes: a Set of all changed files
	// removals: a Set of all removed files
	// watchpack gives up ownership on these Sets.
});

// Watchpack.prototype.pause()
wp.pause();
// stops emitting events, but keeps watchers open
// next "watch" call can reuse the watchers
// The watcher will keep aggregating events
// which can be received with getAggregated()

// Watchpack.prototype.close()
wp.close();
// stops emitting events and closes all watchers

// Watchpack.prototype.getAggregated(): { changes: Set<string>, removals: Set<string> }
const { changes, removals } = wp.getAggregated();
// returns the current aggregated info and removes that from the watcher
// The next aggregated event won't include that info and will only emitted
// when futher changes happen
// Can also be used when paused.

// Watchpack.prototype.collectTimeInfoEntries(fileInfoEntries: Map<string, Entry>, directoryInfoEntries: Map<string, Entry>)
wp.collectTimeInfoEntries(fileInfoEntries, directoryInfoEntries);
// collects time info objects for all known files and directories
// this include info from files not directly watched
// key: absolute path, value: object with { safeTime, timestamp }
// safeTime: a point in time at which it is safe to say all changes happened before that
// timestamp: only for files, the mtime timestamp of the file

// Watchpack.prototype.getTimeInfoEntries()
var fileTimes = wp.getTimeInfoEntries();
// returns a Map with all known time info objects for files and directories
// similar to collectTimeInfoEntries but returns a single map with all entries

// (deprecated)
// Watchpack.prototype.getTimes()
var fileTimes = wp.getTimes();
// returns an object with all known change times for files
// this include timestamps from files not directly watched
// key: absolute path, value: timestamp as number

watchpack's People

Contributors

aghassi avatar alexander-akait avatar benoitzugmeyer avatar danielruf avatar dependabot[bot] avatar donaldpipowitch avatar evilebottnawi avatar ijjk avatar jamesgeorge007 avatar jeffin143 avatar jsoref avatar marksamman avatar mkillianey avatar nkzawa avatar omgftw avatar parikshit-hooda avatar paulmillr avatar pranshuchittora avatar realityking avatar rishabh3112 avatar roblg avatar simonhowey avatar sokra avatar spacek33z avatar thelarkinn avatar tomduncalf avatar wtgtybhertgeghgtwtg avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

watchpack's Issues

Process exits on Bash on Windows

General Information:
webpack version: 1.13.2
OS: Windows 10 Anniversary Update and webpack is running in Windows Subsystem for Linux(The new bash on Ubuntu)

I"m trying to run webpack in watch mode by using:

webpack --watch

and by also setting watch mode in config:

context: path.join(__dirname, '/src'),
devtool: debug ? 'inline-sourcemap' : null,
entry: './js-src/scripts.js',
watch: true,
module: {

All webpack does is run the transpiler and exit.
Example of output when running watch mode:

Hash: 045070ba2ed9ce40edf7
Version: webpack 1.13.2
Time: 2146ms
         Asset     Size  Chunks             Chunk Names
scripts.min.js  1.89 MB       0  [emitted]  main
    + 172 hidden modules

I'm not sure what i'm doing incorrect?

Moved from webpack/webpack#2949

Automatic test itself seems to have problems

Automatic test itself seems to have problems

see: #14

see: #96 (comment)

I found that when I closed pr and reopened pr, these automatic tests have randomness on travis-ci.org. What is the reason?
It should not be a problem I changed.


see: https://travis-ci.org/webpack/watchpack/builds/492544114?utm_source=github_status&utm_medium=notification
image


see: https://travis-ci.org/webpack/watchpack/builds/492541145?utm_source=github_status&utm_medium=notification
image

webpack watch doesn't work, i run npm test, fails~ what's going on? node:6.6.0,npm:3.10.3,webpack:1.13.2

[email protected] pretest /home/duoyi/learning/webpackEs6/node_modules/watchpack
npm run lint

[email protected] lint /home/duoyi/learning/webpackEs6/node_modules/watchpack
eslint lib

[email protected] test /home/duoyi/learning/webpackEs6/node_modules/watchpack
mocha

DirectoryWatcher
1) should detect a file creation
DirectoryWatcher (/home/duoyi/learning/webpackEs6/node_modules/watchpack/test/fixtures) was not closed.
2) should detect a file change
DirectoryWatcher (/home/duoyi/learning/webpackEs6/node_modules/watchpack/test/fixtures) was not closed.
✓ should not detect a file change in initial scan (202ms)
✓ should detect a file change in initial scan with start date (2005ms)
✓ should not detect a file change in initial scan without start date (202ms)
3) should detect multiple file changes (slow)
DirectoryWatcher (/home/duoyi/learning/webpackEs6/node_modules/watchpack/test/fixtures) was not closed.
4) should detect multiple file changes (fast)
DirectoryWatcher (/home/duoyi/learning/webpackEs6/node_modules/watchpack/test/fixtures) was not closed.

Watchpack
5) should watch a single file
6) "after each" hook

3 passing (58s)
6 failing

  1. DirectoryWatcher should detect a file creation:
    Error: timeout of 10000ms exceeded. Ensure the done() callback is being called in this test.

  2. DirectoryWatcher should detect a file change:
    Error: timeout of 10000ms exceeded. Ensure the done() callback is being called in this test.

  3. DirectoryWatcher should detect multiple file changes (slow):
    Error: timeout of 10000ms exceeded. Ensure the done() callback is being called in this test.

  4. DirectoryWatcher should detect multiple file changes (fast):
    Error: timeout of 10000ms exceeded. Ensure the done() callback is being called in this test.

  5. Watchpack should watch a single file:
    Error: timeout of 10000ms exceeded. Ensure the done() callback is being called in this test.

  6. Watchpack "after each" hook:

  Uncaught AssertionError: expected [

'/home/duoyi/learning/webpackEs6/node_modules/watchpack/test/fixtures {}'
] to equal [](at length, A has 1 and B has 0)
+ expected - actual

  -[
  -  "/home/duoyi/learning/webpackEs6/node_modules/watchpack/test/fixtures {}"
  -]
  +[]

  at Assertion.fail (node_modules/should/lib/assertion.js:183:17)
  at Proxy.prop.(anonymous function) (node_modules/should/lib/assertion.js:68:17)
  at TestHelper.<anonymous> (test/helpers/TestHelper.js:31:59)
  at Timeout._onTimeout (test/helpers/TestHelper.js:59:3)

npm ERR! Test failed. See above for more details.

Webpack with Kendo UI

Hi soka,

Recently, I switched from requirejs to webpack and I really like what webpack offers. When I integrate Kendo UI with webpack, it gives me error (tt is undefined) during webpack build. I did some research and it turned out that Webpack does not work well with the *.min.js file (minified). I'm currently using the trial version of Kendo UI which only offers minified file of their product. I have to purchase the license before they can give me the full source codes. My question is will full source codes version work with Webpack? Please note I can not refund if it does not work with Webpack. Would you please give me an expert advise on this?

cheers,
Khoa

Tests fail on FreeBSD 10

I'm investigating an issue with two upstream packages, https://github.com/gaearon/react-hot-loader and https://github.com/webpack/webpack-dev-server with this symptom:

  • I can save a file once, a file change will be detected.
  • I can edit the file again, and the subsequent change won't be detected.

Package cloned from https://github.com/webpack/watchpack/releases/tag/v0.2.8.

{ name: 'watchpack',
  'dist-tags': { latest: '0.2.8' },
  versions: 
   [ '0.1.0',
     '0.1.1',
     '0.1.2',
     '0.1.3',
     '0.2.0',
     '0.2.1',
     '0.2.2',
     '0.2.3',
     '0.2.4',
     '0.2.5',
     '0.2.6',
     '0.2.7',
     '0.2.8' ],
  maintainers: 'sokra <[email protected]>',
  time: 
   { modified: '2015-05-10T12:35:28.755Z',
     created: '2014-10-09T06:48:51.514Z',
     '0.1.0': '2014-10-09T06:48:51.514Z',
     '0.1.1': '2014-11-02T22:53:10.008Z',
     '0.1.2': '2014-11-11T23:07:10.341Z',
     '0.1.3': '2014-11-18T22:53:53.283Z',
     '0.2.0': '2015-01-17T18:12:02.174Z',
     '0.2.1': '2015-01-17T20:50:59.908Z',
     '0.2.2': '2015-01-20T22:45:35.020Z',
     '0.2.3': '2015-01-24T09:50:39.292Z',
     '0.2.4': '2015-04-09T14:36:32.928Z',
     '0.2.5': '2015-04-30T18:50:59.017Z',
     '0.2.6': '2015-05-03T21:05:25.570Z',
     '0.2.7': '2015-05-10T11:33:12.879Z',
     '0.2.8': '2015-05-10T12:35:28.755Z' },
  homepage: 'https://github.com/webpack/watchpack',
  repository: 
   { type: 'git',
     url: 'git+https://github.com/webpack/watchpack.git' },
  author: 'Tobias Koppers @sokra',
  bugs: { url: 'https://github.com/webpack/watchpack/issues' },
  license: 'MIT',
  readmeFilename: 'README.md',
  description: 'Wrapper library for directory and file watching.',
  version: '0.2.8',
  main: './lib/watchpack.js',
  directories: { test: 'test' },
  scripts: 
   { pretest: 'npm run lint',
     test: 'mocha',
     travis: 'npm run cover -- --report lcovonly',
     lint: 'eslint lib',
     precover: 'npm run lint',
     cover: 'istanbul cover node_modules/mocha/bin/_mocha' },
  devDependencies: 
   { coveralls: '^2.11.2',
     eslint: '^0.20.0',
     istanbul: '^0.3.13',
     mocha: '^2.1.0',
     rimraf: '^2.2.8',
     should: '^6.0.1' },
  dependencies: { async: '^0.9.0', chokidar: '^1.0.0', 'graceful-fs': '^3.0.2' },
  gitHead: '3f5ec9863c36dbee8b5e3d9a2a730c1f3d02b993',
  dist: 
   { shasum: '3234d3648e72a43f25c225fb8ff12877d3f4ac47',
     tarball: 'http://registry.npmjs.org/watchpack/-/watchpack-0.2.8.tgz' } }

System:

$ uname -apKU
FreeBSD z600 10.2-PRERELEASE FreeBSD 10.2-PRERELEASE #5: Fri Jun 26 10:34:21 CDT 2015     root@z600:/usr/obj/usr/src/sys/MYKERNEL  amd64 amd64 1001519 1001519

Output of

> [email protected] pretest /usr/home/tony/work/watchpack
> npm run lint


> [email protected] lint /usr/home/tony/work/watchpack
> eslint lib


> [email protected] test /usr/home/tony/work/watchpack
> mocha



  DirectoryWatcher

    ✓ should detect a file creation (128ms)

    1) should detect a file change
DirectoryWatcher (/usr/home/tony/work/watchpack/test/fixtures) was not closed.

    ✓ should not detect a file change in initial scan (211ms)

    ✓ should detect a file change in initial scan with start date (2013ms)

    ✓ should not detect a file change in initial scan without start date (205ms)

    2) should detect multiple file changes (slow)
DirectoryWatcher (/usr/home/tony/work/watchpack/test/fixtures) was not closed.

    3) should detect multiple file changes (fast)
DirectoryWatcher (/usr/home/tony/work/watchpack/test/fixtures) was not closed.

  Watchpack

    ✓ should watch a single file (1133ms)

    4) should watch multiple files

    5) "after each" hook

  5 passing (41s)
  5 failing

  1) DirectoryWatcher should detect a file change:
     Error: timeout of 10000ms exceeded. Ensure the done() callback is being called in this test.


  2) DirectoryWatcher should detect multiple file changes (slow):
     Error: timeout of 10000ms exceeded. Ensure the done() callback is being called in this test.


  3) DirectoryWatcher should detect multiple file changes (fast):
     Error: timeout of 10000ms exceeded. Ensure the done() callback is being called in this test.


  4) Watchpack should watch multiple files:

      Uncaught expected [
  '/usr/home/tony/work/watchpack/test/fixtures/a',
  '/usr/home/tony/work/watchpack/test/fixtures/b'
] to equal [
  '/usr/home/tony/work/watchpack/test/fixtures/a',
  '/usr/home/tony/work/watchpack/test/fixtures/b',
  '/usr/home/tony/work/watchpack/test/fixtures/a',
  '/usr/home/tony/work/watchpack/test/fixtures/b',
  '/usr/home/tony/work/watchpack/test/fixtures/a'
] (at length, A has 2 and B has 5)
      + expected - actual

       [
         "/usr/home/tony/work/watchpack/test/fixtures/a"
         "/usr/home/tony/work/watchpack/test/fixtures/b"
      +  "/usr/home/tony/work/watchpack/test/fixtures/a"
      +  "/usr/home/tony/work/watchpack/test/fixtures/b"
      +  "/usr/home/tony/work/watchpack/test/fixtures/a"
       ]

  AssertionError: expected [
    'test/fixtures/a',
    'test/fixtures/b'
  ] to equal [
    'test/fixtures/a',
    'test/fixtures/b',
    'test/fixtures/a',
    'test/fixtures/b',
    'test/fixtures/a'
  ] (at length, A has 2 and B has 5)
      at EventEmitter.<anonymous> (test/watchpack.js:48:27)
      at EventEmitter._onTimeout (lib/watchpack.js:121:7)

  5) Watchpack "after each" hook:

      Uncaught expected [ '/usr/home/tony/work/watchpack/test/fixtures {}' ] to equal [] (at length, A has 1 and B has 0)
      + expected - actual

      -[
      -  "/usr/home/tony/work/watchpack/test/fixtures {}"
      -]
      +[]

  AssertionError: expected [ 'test/fixtures {}' ] to equal [] (at length, A has 1 and B has 0)
      at TestHelper.<anonymous> (test/helpers/TestHelper.js:31:59)
      at null._onTimeout (test/helpers/TestHelper.js:59:3)

failing unit tests on Node.js 4

I'll probably investigate this but these should not fail. Not yet sure if this is due to the (dev)dependencies or other changes.

Recompiles continuously until recently modified file is 10 seconds old

Hello,

I'm using webpack-dev-server and a custom script to build and view a project I'm working on. I run it like this:

./docs/scripts/index.js && webpack-dev-server

The Node script creates a JSON file that is required in my bundle and that webpack-dev-server watches. The problem, however, is that webpack-dev-sever will constantly recompile until the JSON file is 10 seconds old.

Below is the console output. I've added my own console.log's within watchpack (prefixed by ***) to monitor the timestamps. The recompilation loop ends when the timestamp in DirectoryWatcher.js (L178) is at least 10,000 more than the timestamp in watchpack.js (L100).

*** DirectoryWatcher.js 1495481025082
Hash: f6e60d3196316658e060
Version: webpack 2.5.1
Time: 1905ms
    Asset     Size  Chunks                    Chunk Names
bundle.js  1.05 MB       0  [emitted]  [big]  main
chunk    {0} bundle.js (main) 1.02 MB [entry] [rendered]
   [26] ./~/react/lib/React.js 3.32 kB {0} [built]
  [100] ./~/react/react.js 56 bytes {0} [built]
  [116] ./docs/index.js 1.17 kB {0} [built]
  [117] (webpack)-dev-server/client?http://localhost:8080 5.68 kB {0} [built]
  [120] ./packages/tp-react-button/index.js 770 bytes {0} [built]
  [140] ./packages/tp-react-button/dist/props.json 398 bytes {0} [built]
  [145] ./~/punycode/punycode.js 14.7 kB {0} [built]
  [150] ./~/react-dom/index.js 59 bytes {0} [built]
  [164] ./~/react-dom/lib/ReactDOM.js 5.14 kB {0} [built]
  [261] ./~/strip-ansi/index.js 161 bytes {0} [built]
  [262] ./~/url/url.js 23.3 kB {0} [built]
  [264] (webpack)-dev-server/client/overlay.js 3.73 kB {0} [built]
  [265] (webpack)-dev-server/client/socket.js 897 bytes {0} [built]
  [267] (webpack)/hot/emitter.js 77 bytes {0} [built]
  [268] multi (webpack)-dev-server/client?http://localhost:8080 ./docs/index.js 40 bytes {0} [built]
     + 254 hidden modules
webpack: Compiled successfully.
*** watchpack.js 1495481034000
webpack: Compiling...
*** DirectoryWatcher.js 1495481027271
Hash: f6e60d3196316658e060
Version: webpack 2.5.1
Time: 66ms
chunk    {0} bundle.js (main) 1.02 MB [entry]
  [140] ./packages/tp-react-button/dist/props.json 398 bytes {0} [built]
     + 268 hidden modules
webpack: Compiled successfully.
*** watchpack.js 1495481024000
webpack: Compiling...
*** DirectoryWatcher.js 1495481027556
Hash: f6e60d3196316658e060
Version: webpack 2.5.1
Time: 20ms
chunk    {0} bundle.js (main) 1.02 MB [entry]
  [140] ./packages/tp-react-button/dist/props.json 398 bytes {0} [built]
     + 268 hidden modules
webpack: Compiled successfully.
*** watchpack.js 1495481024000
webpack: Compiling...
*** DirectoryWatcher.js 1495481027794
Hash: f6e60d3196316658e060
Version: webpack 2.5.1
Time: 27ms
chunk    {0} bundle.js (main) 1.02 MB [entry]
  [140] ./packages/tp-react-button/dist/props.json 398 bytes {0} [built]
     + 268 hidden modules
webpack: Compiled successfully.
*** watchpack.js 1495481024000
webpack: Compiling...
*** DirectoryWatcher.js 1495481028041
Hash: f6e60d3196316658e060
Version: webpack 2.5.1
Time: 19ms
chunk    {0} bundle.js (main) 1.02 MB [entry]
  [140] ./packages/tp-react-button/dist/props.json 398 bytes {0} [built]
     + 268 hidden modules
webpack: Compiled successfully.
*** watchpack.js 1495481024000
webpack: Compiling...
*** DirectoryWatcher.js 1495481028288
Hash: f6e60d3196316658e060
Version: webpack 2.5.1
Time: 17ms
chunk    {0} bundle.js (main) 1.02 MB [entry]
  [140] ./packages/tp-react-button/dist/props.json 398 bytes {0} [built]
     + 268 hidden modules
webpack: Compiled successfully.
*** watchpack.js 1495481024000
webpack: Compiling...
*** DirectoryWatcher.js 1495481028523
Hash: f6e60d3196316658e060
Version: webpack 2.5.1
Time: 24ms
chunk    {0} bundle.js (main) 1.02 MB [entry]
  [140] ./packages/tp-react-button/dist/props.json 398 bytes {0} [built]
     + 268 hidden modules
webpack: Compiled successfully.
*** watchpack.js 1495481024000
webpack: Compiling...
*** DirectoryWatcher.js 1495481028762
Hash: f6e60d3196316658e060
Version: webpack 2.5.1
Time: 21ms
chunk    {0} bundle.js (main) 1.02 MB [entry]
  [140] ./packages/tp-react-button/dist/props.json 398 bytes {0} [built]
     + 268 hidden modules
webpack: Compiled successfully.
*** watchpack.js 1495481024000
webpack: Compiling...
*** DirectoryWatcher.js 1495481029002
Hash: f6e60d3196316658e060
Version: webpack 2.5.1
Time: 28ms
chunk    {0} bundle.js (main) 1.02 MB [entry]
  [140] ./packages/tp-react-button/dist/props.json 398 bytes {0} [built]
     + 268 hidden modules
webpack: Compiled successfully.
*** watchpack.js 1495481024000
webpack: Compiling...
*** DirectoryWatcher.js 1495481029244
Hash: f6e60d3196316658e060
Version: webpack 2.5.1
Time: 20ms
chunk    {0} bundle.js (main) 1.02 MB [entry]
  [140] ./packages/tp-react-button/dist/props.json 398 bytes {0} [built]
     + 268 hidden modules
webpack: Compiled successfully.
*** watchpack.js 1495481024000
webpack: Compiling...
*** DirectoryWatcher.js 1495481029489
Hash: f6e60d3196316658e060
Version: webpack 2.5.1
Time: 17ms
chunk    {0} bundle.js (main) 1.02 MB [entry]
  [140] ./packages/tp-react-button/dist/props.json 398 bytes {0} [built]
     + 268 hidden modules
webpack: Compiled successfully.
*** watchpack.js 1495481024000
webpack: Compiling...
*** DirectoryWatcher.js 1495481029726
Hash: f6e60d3196316658e060
Version: webpack 2.5.1
Time: 31ms
chunk    {0} bundle.js (main) 1.02 MB [entry]
  [140] ./packages/tp-react-button/dist/props.json 398 bytes {0} [built]
     + 268 hidden modules
webpack: Compiled successfully.
*** watchpack.js 1495481024000
webpack: Compiling...
*** DirectoryWatcher.js 1495481029972
Hash: f6e60d3196316658e060
Version: webpack 2.5.1
Time: 18ms
chunk    {0} bundle.js (main) 1.02 MB [entry]
  [140] ./packages/tp-react-button/dist/props.json 398 bytes {0} [built]
     + 268 hidden modules
webpack: Compiled successfully.
*** watchpack.js 1495481024000
webpack: Compiling...
*** DirectoryWatcher.js 1495481030206
Hash: f6e60d3196316658e060
Version: webpack 2.5.1
Time: 26ms
chunk    {0} bundle.js (main) 1.02 MB [entry]
  [140] ./packages/tp-react-button/dist/props.json 398 bytes {0} [built]
     + 268 hidden modules
webpack: Compiled successfully.
*** watchpack.js 1495481024000
webpack: Compiling...
*** DirectoryWatcher.js 1495481030451
Hash: f6e60d3196316658e060
Version: webpack 2.5.1
Time: 26ms
chunk    {0} bundle.js (main) 1.02 MB [entry]
  [140] ./packages/tp-react-button/dist/props.json 398 bytes {0} [built]
     + 268 hidden modules
webpack: Compiled successfully.
*** watchpack.js 1495481024000
webpack: Compiling...
*** DirectoryWatcher.js 1495481030697
Hash: f6e60d3196316658e060
Version: webpack 2.5.1
Time: 17ms
chunk    {0} bundle.js (main) 1.02 MB [entry]
  [140] ./packages/tp-react-button/dist/props.json 398 bytes {0} [built]
     + 268 hidden modules
webpack: Compiled successfully.
*** watchpack.js 1495481024000
webpack: Compiling...
*** DirectoryWatcher.js 1495481030932
Hash: f6e60d3196316658e060
Version: webpack 2.5.1
Time: 26ms
chunk    {0} bundle.js (main) 1.02 MB [entry]
  [140] ./packages/tp-react-button/dist/props.json 398 bytes {0} [built]
     + 268 hidden modules
webpack: Compiled successfully.
*** watchpack.js 1495481024000
webpack: Compiling...
*** DirectoryWatcher.js 1495481031176
Hash: f6e60d3196316658e060
Version: webpack 2.5.1
Time: 17ms
chunk    {0} bundle.js (main) 1.02 MB [entry]
  [140] ./packages/tp-react-button/dist/props.json 398 bytes {0} [built]
     + 268 hidden modules
webpack: Compiled successfully.
*** watchpack.js 1495481024000
webpack: Compiling...
*** DirectoryWatcher.js 1495481031421
Hash: f6e60d3196316658e060
Version: webpack 2.5.1
Time: 17ms
chunk    {0} bundle.js (main) 1.02 MB [entry]
  [140] ./packages/tp-react-button/dist/props.json 398 bytes {0} [built]
     + 268 hidden modules
webpack: Compiled successfully.
*** watchpack.js 1495481024000
webpack: Compiling...
*** DirectoryWatcher.js 1495481031656
Hash: f6e60d3196316658e060
Version: webpack 2.5.1
Time: 25ms
chunk    {0} bundle.js (main) 1.02 MB [entry]
  [140] ./packages/tp-react-button/dist/props.json 398 bytes {0} [built]
     + 268 hidden modules
webpack: Compiled successfully.
*** watchpack.js 1495481024000
webpack: Compiling...
*** DirectoryWatcher.js 1495481031902
Hash: f6e60d3196316658e060
Version: webpack 2.5.1
Time: 18ms
chunk    {0} bundle.js (main) 1.02 MB [entry]
  [140] ./packages/tp-react-button/dist/props.json 398 bytes {0} [built]
     + 268 hidden modules
webpack: Compiled successfully.
*** watchpack.js 1495481024000
webpack: Compiling...
*** DirectoryWatcher.js 1495481032139
Hash: f6e60d3196316658e060
Version: webpack 2.5.1
Time: 27ms
chunk    {0} bundle.js (main) 1.02 MB [entry]
  [140] ./packages/tp-react-button/dist/props.json 398 bytes {0} [built]
     + 268 hidden modules
webpack: Compiled successfully.
*** watchpack.js 1495481024000
webpack: Compiling...
*** DirectoryWatcher.js 1495481032382
Hash: f6e60d3196316658e060
Version: webpack 2.5.1
Time: 16ms
chunk    {0} bundle.js (main) 1.02 MB [entry]
  [140] ./packages/tp-react-button/dist/props.json 398 bytes {0} [built]
     + 268 hidden modules
webpack: Compiled successfully.
*** watchpack.js 1495481024000
webpack: Compiling...
*** DirectoryWatcher.js 1495481032627
Hash: f6e60d3196316658e060
Version: webpack 2.5.1
Time: 18ms
chunk    {0} bundle.js (main) 1.02 MB [entry]
  [140] ./packages/tp-react-button/dist/props.json 398 bytes {0} [built]
     + 268 hidden modules
webpack: Compiled successfully.
*** watchpack.js 1495481024000
webpack: Compiling...
*** DirectoryWatcher.js 1495481032860
Hash: f6e60d3196316658e060
Version: webpack 2.5.1
Time: 23ms
chunk    {0} bundle.js (main) 1.02 MB [entry]
  [140] ./packages/tp-react-button/dist/props.json 398 bytes {0} [built]
     + 268 hidden modules
webpack: Compiled successfully.
*** watchpack.js 1495481024000
webpack: Compiling...
*** DirectoryWatcher.js 1495481033101
Hash: f6e60d3196316658e060
Version: webpack 2.5.1
Time: 17ms
chunk    {0} bundle.js (main) 1.02 MB [entry]
  [140] ./packages/tp-react-button/dist/props.json 398 bytes {0} [built]
     + 268 hidden modules
webpack: Compiled successfully.
*** watchpack.js 1495481024000
webpack: Compiling...
*** DirectoryWatcher.js 1495481033339
Hash: f6e60d3196316658e060
Version: webpack 2.5.1
Time: 28ms
chunk    {0} bundle.js (main) 1.02 MB [entry]
  [140] ./packages/tp-react-button/dist/props.json 398 bytes {0} [built]
     + 268 hidden modules
webpack: Compiled successfully.
*** watchpack.js 1495481024000
webpack: Compiling...
*** DirectoryWatcher.js 1495481033583
Hash: f6e60d3196316658e060
Version: webpack 2.5.1
Time: 17ms
chunk    {0} bundle.js (main) 1.02 MB [entry]
  [140] ./packages/tp-react-button/dist/props.json 398 bytes {0} [built]
     + 268 hidden modules
webpack: Compiled successfully.
*** watchpack.js 1495481024000
webpack: Compiling...
*** DirectoryWatcher.js 1495481033823
Hash: f6e60d3196316658e060
Version: webpack 2.5.1
Time: 16ms
chunk    {0} bundle.js (main) 1.02 MB [entry]
  [140] ./packages/tp-react-button/dist/props.json 398 bytes {0} [built]
     + 268 hidden modules
webpack: Compiled successfully.
*** watchpack.js 1495481024000
webpack: Compiling...
*** DirectoryWatcher.js 1495481034058
Hash: f6e60d3196316658e060
Version: webpack 2.5.1
Time: 25ms
chunk    {0} bundle.js (main) 1.02 MB [entry]
  [140] ./packages/tp-react-button/dist/props.json 398 bytes {0} [built]
     + 268 hidden modules
webpack: Compiled successfully.

I do not see this problem if I run the documentation script first, manually wait ten seconds, then run webpack-dev-server.

The number seems to correspond to FS_ACCURACY, but I don't understand how that works.

Does not detect minor changes to the file (added/removed whitespace, semicolon)

Subject:

let foo

console.log('abc', foo);

I am using:

  • webpack
  • eslint-loader

I am running webpack using webpack --watch --progress.

The following output is generated:

ERROR in ./foo.js

/foo.js
  1:7  error  Missing semicolon  semi

✖ 1 problem (1 error, 0 warnings)

So far so good.

I edit the subject file:

let foo;

console.log('abc', foo);

webpack CLI --progress indicates that package is re-built. However, error output remains.

I edit the subject file (edit the string):

let foo;

console.log('def', foo);

webpack CLI --progress indicates that package is re-built. The error disappears.

Therefore, it appears that adding/removing a semicolon does not trigger loaders.

onFileAdded: cannot read property 'mtime' of undefined

I get this error occasionally in onFileAdded when using webpack compiler.watch. I haven't been able to track down an exact repro.

project/node_modules/webpack/node_modules/watchpack/lib/DirectoryWatcher.js:211
        this.setFileTime(filePath, +stat.mtime, false, "add");
                                        ^
TypeError: Cannot read property 'mtime' of undefined
    at DirectoryWatcher.onFileAdded (project/node_modules/webpack/node_modules/watchpack/lib/DirectoryWatcher.js:211:34)
    at EventEmitter.emit (events.js:98:17)
    at EventEmitter.<anonymous> (project/node_modules/webpack/node_modules/watchpack/node_modules/chokidar/index.js:135:15)
    at project/node_modules/webpack/node_modules/watchpack/node_modules/chokidar/index.js:145:7
    at Object.oncomplete (fs.js:107:15)

I wonder if it might be related to this commit?
9681996

I see that chokidar is supposed to always provide the stat value, so I don't see how this could happen. Maybe it is a problem with chokidar?

Sporadic watching inside virtual machine

First, I would like to start by saying this is not happening in an NFS (shared) folder of a virtual machine.

When I bring up a virtual machine with VMWare or Virtualbox with a guest OS of Ubuntu 15.10 on a Windows 10 Host, changes are only picked up occasionally by webpack. If I save in succession 5-10 times I will likely have webpack recompile 1 time. I have upped the number of watchers according to the troubleshooting guide.

I hastily posted this while at work but I will make sure to see if the tests pass when I get home.

Has anybody ran into this issue?

Watch doesn`t work correctly with links

Do you want to request a feature or report a bug?
Bug report.

What is the current behavior?
When i create link in node_modules and set symlinks to false, I have problem with watch, it works sometimes (more often it doesn`t work)

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

  1. create link
  2. set symlinks to false
  3. change file by link

What is the expected behavior?
Watch must work

If this is a feature request, what is motivation or use case for changing the behavior?

Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.

node v8.9.3
npm 5.6.0
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial
4.4.0-83-generic
webpack 3.10.0


This issue was moved from webpack/webpack#6122 by @sokra. Orginal issue was by @arshtepe.

@evilebottnawi I have created repo https://bitbucket.org/CyBer_UA/webpack-demo/src/344771d7d4b403eb662a9c0e7f23aaedc920f0e9?at=master
To reproduce you need:

cd repo/
npm link
cd ..
npm link simple-repo
webpack --watch

and after that you need to change file index.js in repo folder
from

import test from "src/test";

to

import test from "./src/test"; 

and after webpack do nothing...

Passing options to chokidar (watching broken over NFS)

Similar to watchify#162, I believe it would be best to allow the user to pass chokidar options to watchpack. Without the ability to opt into usePolling, webpack's watching is unresponsive when watching files mounted over NFS (which can't implement inotify/fsevents or the like). I imagine that adjusting the poll frequency would be great too. If this happens we'd have to implement the passing through webpack as well.

I tried the old watcher plugin and it does not seem to fix this issue either, but let me know otherwise.

Silent fail when fs.inotify.max_user_watches is exceeded

Docker container configuration

  • Webpack 1.10.3
  • Node v0.10.25
  • Ubuntu 15.04

Host configuration

  • Docker 1.0.1
  • Ubuntu 14.04

Issue

Running webpack --watch in docker container successfully performs one build and then exits with exit code 0 (success).

Expectation

Some kind of error code and a return code != 0 if max_user_watches is exceeded.

Workaround

Increasing /proc/sys/fs/inotify/max_user_watches on the host system fixes the problem.

Moved from webpack/webpack#1281

Update async?

Perhaps there's something I should/could be doing to avoid this. If so, let me know. But I just updated to the latest version of async (1.3.0) and I'm now getting this:

npm WARN unmet dependency /Users/kentcdodds/Developer/alianza/admin-portal/node_modules/webpack/node_modules/watchpack requires async@'^0.9.0' but will load
npm WARN unmet dependency /Users/kentcdodds/Developer/alianza/admin-portal/node_modules/async,
npm WARN unmet dependency which is version 1.3.0

I'd like to avoid the noise of these warnings. Is there any issue with updating the dependency to be ^0.9.0 || ^1.x so I can upgrade without having the warnings?

linked issues: webpack-contrib/source-map-loader#7 webpack/webpack#1257

require.context watch

I am creating context with require.context and then if I delete one of the files - context still have file in keys

function resolveModule(m) {
  return m && (m['default'] || m);
}
var initializers = require.context('./app/initializers', true, /^\.\/.*\.(coffee|js)$/);
initializers.keys().forEach(function (key) {
  App.initializer(resolveModule(initializers(key)));
});

then i do touch ./app/initializers/module.js - webpack adds lt to bundle

Time: 317ms
                               Asset      Size  Chunks             Chunk Names
                             main.js      5 MB       0  [emitted]  main
0.26199a81b8b82c2a54c6.hot-update.js   4.16 kB       0  [emitted]  main
26199a81b8b82c2a54c6.hot-update.json  36 bytes          [emitted]  
chunk    {0} main.js, 0.26199a81b8b82c2a54c6.hot-update.js (main) 4.62 MB [rendered]
    [1] ./main.js 1.91 kB {0} [built]
    [8] ./app/initializers ^\.\/.*\.(coffee|js)$ 270 bytes {0} [built]
  [315] ./app/initializers/module.js 13 bytes {0} [optional] [built]
     + 313 hidden modules
webpack: bundle is now VALID.

then rm ./app/initializers/module.js
all looks good:

webpack: bundle is now INVALID.
Hash: e1f82ca7a04716a03489
Version: webpack 1.8.4
Time: 262ms
                               Asset      Size  Chunks             Chunk Names
                             main.js      5 MB       0  [emitted]  main
0.e3fd8315493bee6aee08.hot-update.js   3.75 kB       0  [emitted]  main
e3fd8315493bee6aee08.hot-update.json  36 bytes          [emitted]  
chunk    {0} main.js, 0.e3fd8315493bee6aee08.hot-update.js (main) 4.62 MB [rendered]
    [1] ./main.js 1.93 kB {0} [built]
     + 314 hidden modules

but on next rebuild I am getting warning

WARNING in ./app/initializers/module.js
Module build failed: Error: ENOENT, open '/Volumes/Seagate/Web/tt/ca-webpackify/app/initializers/module.js'
  at Error (native)

 @ ./app/initializers ^\.\/.*\.(coffee|js)$
webpack: bundle is now VALID.

the problem is that ./module.js is still in the keys of the context.

as a workaround of this issue I just checked for exported module keys. (removed module is exported as empty object)

Watch recursion

So recently I got problems in webpack, where the watcher is spamming "compile" events for files that are updated before watching starts. The rabbit hole was deep, but led me to watchpack.

So:

  1. So at some point doInitialScan is processed in DirectoryWatcher.
  2. This, at least for files, runs setFileTime
  3. As the inital flag is set, this this.files[filePath] = [initial ? Math.min(now, mtime) : now, mtime]; mostly equals to this.files[filePath] = [mtime, mtime];, because the file mtime will be smaller the time now (in case I edited file before running watcher).
  4. Next at some point it gets to process.nextTick and var ts = data[0] === data[1] ? data[0] + FS_ACCURACY : data[0]; and if(ts >= startTime)watcher.emit("change", data[1]);
  5. As this data[0] === data[1] is true (check point 3), FS_ACCURACY is added. So ts is bigger than startTime (delivered from webpack compiler it's self.startTime = Date.now();).
  6. So for aprox 10 seconds (FS_ACCURACY = 10000 milis) it'ss spamming compile events, until the date now reaches file mtime+10 secs.

This doesn't feel right :/

add gaze watcher lib

it would be interesting to add another lib of watcher?

The webpack does not support fsevent in http://azk.io. I believe that the same issue will occur with docker or VMs. I'm thinking of adding the gaze as a watcher optional or default.

use long polling is extremely impractical to consume large amount of resources and still be slow.

Crash error after upgrade required package chokidar to up 1.1.0

I use webpack in watch mode. After upgrade required package chokidar to version up 1.1.0 raise error:

/home/vadim/project/node_modules/webpack/node_modules/watchpack/node_modules/chokidar/node_modules/readdirp/readdirp.js:52
    var api          =  require('./stream-api')();
                                               ^
TypeError: object is not a function
    at readdir (/home/vadim/project/node_modules/webpack/node_modules/watchpack/node_modules/chokidar/node_modules/readdirp/readdirp.js:52:48)
    at EventEmitter.<anonymous> (/home/vadim/project/node_modules/webpack/node_modules/watchpack/node_modules/chokidar/lib/nodefs-handler.js:353:5)
    at EventEmitter.NodeFsHandler._handleDir (/home/vadim/project/node_modules/webpack/node_modules/watchpack/node_modules/chokidar/lib/nodefs-handler.js:402:18)
    at EventEmitter.<anonymous> (/home/vadim/project/node_modules/webpack/node_modules/watchpack/node_modules/chokidar/lib/nodefs-handler.js:450:19)
    at EventEmitter.<anonymous> (/home/vadim/project/node_modules/webpack/node_modules/watchpack/node_modules/chokidar/lib/nodefs-handler.js:455:16)
    at Object.oncomplete (fs.js:108:15)
npm ERR! weird error 8
npm ERR! not ok code 0

With [email protected] with error don't raise.

NSP check is reporting vulnerability on latest Webpack package.

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

What is the current behavior?

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

What is the expected behavior?

If this is a feature request, what is motivation or use case for changing the behavior?

Please mention other relevant information such as the browser version, Node.js version, webpack version, and Operating System.

Just executed the nsp check command on my project and it is reporting a vulnerability on latest webpack package due to a downstream dependency on the module hoek.
Please refer the link from node security: https://nodesecurity.io/advisories/566

Path: webpack >> [email protected]>>[email protected]>>[email protected]>>[email protected]>>hawk>>hoek


This issue was moved from webpack/webpack#6513 by @evilebottnawi. Orginal issue was by @sneharghya.

Why is followSymlinks disabled?

I have several projects which uses npm link to share modules and I've noticed that webpack HMR wouldn't work from these symlinks.
After investigating I've noticed that in the chokidar.watch call passes in the options followSymlinks: false.
I wanted to ask how come and if you are willing to change it to true :)
That's all I need to use HMR with my npm links.
I can have a PR ready in a minute :)

Improve documentation regarding CSPs

I'm creating this issue as a result of webpack/webpack.js.org#1833 (comment). The current docs regarding how the __webpack_nonce__ should be used are still lacking necessary information.

  • Where to put __webpack_nonce__
    • Is it a build-time setting
    • How to inject if it is not a build-time setting? (does setting window.__webpack_nonce__ work?)
  • Are there any hooks?

Consider moving from `chokidar` to `sane`.

sane is the filesystem watcher used by jest-cli. It supports Linux, OS X, and Windows, and can use watchman if available. More notably, its dependency tree is significantly smaller than the dependency tree for chokidar.
Keep in mind that fsevents should only be required in OS X systems.
I played around with it for an hour or two and, for the most part, sane seemed to be able to take the place of chokidar without issue. Would something like this be considered?

Hot Module Replacement doesn't notice when a symlink is changed

What is the current behavior?
We symlink our node_modules directory and change the symlink when we update node_modules. When the directory is changes HMR doesn't detect that something has changed.

If the current behavior is a bug, please provide the steps to reproduce.
Setup HMR referencing a file with the parent directory symlinked. Change the symlink to a different directory with a modified version of the file.

What is the expected behavior?
HMR should detect that files have changed. Currently does not.

Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.
Linux Ubuntu.


This issue was moved from webpack/webpack#5395 by @sokra. Orginal issue was by @pweaver.

TypeError: DirectoryWatcher is not a constructor

We have a repeating error appearing when running tests of our application (using jest, if it matters; using the project set up via https://github.com/react-boilerplate/react-boilerplate). Is this error caused by our (or react-boilerplate) misconfiguration somewhere, or it is a problem in watchpack itself?

/app/node_modules/watchpack/lib/watcherManager.js:18
                this.directoryWatchers[key] = new DirectoryWatcher(directory, options);
                                              ^

TypeError: DirectoryWatcher is not a constructor
    at WatcherManager.Object.<anonymous>.WatcherManager.getDirectoryWatcher (/app/node_modules/watchpack/lib/watcherManager.js:18:33)
    at WatcherManager.watchFile (/app/node_modules/watchpack/lib/watcherManager.js:28:14)
    at Watchpack.<anonymous> (/app/node_modules/watchpack/lib/watchpack.js:38:49)
    at Array.map (<anonymous>)
    at Watchpack.watch (/app/node_modules/watchpack/lib/watchpack.js:37:28)
    at NodeWatchFileSystem.watch (/app/node_modules/webpack/lib/node/NodeWatchFileSystem.js:70:16)
    at Watching.watch (/app/node_modules/webpack/lib/Watching.js:113:48)
    at compiler.hooks.done.callAsync (/app/node_modules/webpack/lib/Watching.js:100:10)
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/app/node_modules/webpack/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:15:1)
    at AsyncSeriesHook.lazyCompileHook (/app/node_modules/webpack/node_modules/tapable/lib/Hook.js:154:20)
    at Watching._done (/app/node_modules/webpack/lib/Watching.js:97:28)
    at compiler.emitRecords.err (/app/node_modules/webpack/lib/Watching.js:72:19)
    at Compiler.emitRecords (/app/node_modules/webpack/lib/Compiler.js:449:39)
    at compiler.emitAssets.err (/app/node_modules/webpack/lib/Watching.js:53:20)
    at hooks.afterEmit.callAsync.err (/app/node_modules/webpack/lib/Compiler.js:435:14)
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/app/node_modules/webpack/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:15:1)
    at AsyncSeriesHook.lazyCompileHook (/app/node_modules/webpack/node_modules/tapable/lib/Hook.js:154:20)
    at asyncLib.forEachLimit.err (/app/node_modules/webpack/lib/Compiler.js:432:27)
    at /app/node_modules/neo-async/async.js:2813:7
    at done (/app/node_modules/neo-async/async.js:3521:9)
    at MemoryFileSystem.Object.<anonymous>.MemoryFileSystem.writeFile (/app/node_modules/webpack-dev-middleware/node_modules/memory-fs/lib/MemoryFileSystem.js:328:9)
    at writeOut (/app/node_modules/webpack/lib/Compiler.js:415:30)
    at asyncLib.forEachLimit (/app/node_modules/webpack/lib/Compiler.js:426:7)
    at objectIteratorWithKey (/app/node_modules/neo-async/async.js:3508:9)
    at timesSync (/app/node_modules/neo-async/async.js:2292:7)
    at Object.eachLimit (/app/node_modules/neo-async/async.js:3463:5)
    at emitFiles (/app/node_modules/webpack/lib/Compiler.js:321:13)
    at Immediate._onImmediate (/app/node_modules/webpack-dev-middleware/node_modules/memory-fs/lib/MemoryFileSystem.js:288:4)
    at runCallback (timers.js:810:20)
    at tryOnImmediate (timers.js:768:5)
    at processImmediate [as _immediateCallback] (timers.js:745:5)

Uses a ton of CPU in polling mode

Hi,

I'm developing an app and switching over to using Docker containers for some of it. Since I'm running OS X, I'm running Docker in Vagrant and using NFS to share my working directory, then building containers from the code in that directory.

It can be difficult to find a file watcher that works properly over NFS. Nodemon fails, pm2 eats up CPU, but node-supervisor seems to do well by just doing a slow poll. I get great <1% CPU usage watching with supervisor.

Unfortunately, webpack-dev-server with the old watcher doesn't catch changes at all, so I'm using NewWatchingPlugin. It does catch changes, but it pegs me at about 220% CPU (5 threads)!

I've played around with the invocation of Chokidar in DirectoryWatcher. Setting the polling interval to 5000 gets the CPU usage down quite a bit, to about 30%. It is obviously very slow to react, though, and that's still much higher than I would like.

I stuck a logging statement at the invocation of Chokidar and found that it's watching about 90-100 directories; every single module my project imports, as well as all of the project folders. It's easy to see how, with polling, this could get expensive.

Is it possible to:

  1. Make this more efficient by coalescing into a single polling watcher instead of 100?
  2. Do the watching instead from the host OS (which can use FSEvents) and signal to webpack inside the container somehow (create a file, have it listen on a port, etc)? Either the host OS could rebuild, or webpack in the container could.

The solution doesn't have to be super-elegant; this is just a dev environment.

watchpack watch not triggering when symlinked node_module files are modified when using webpack 'symlinks: true'

In a regular webpack project, a symlinked module in node_modules is watched for changes correctly (as long as the module in question is referenced).

However, if using 'symlinks:true' in webpack to resolve symlinks to their full path (e.g. when using --preserve-symlinks behaviour in angular-cli), it does not seem to watch for changes anymore.

I have tracked this behaviour down to the 'followSymlinks' option of DirectoryWatcher in watchpack (https://github.com/webpack/watchpack/blob/master/lib/DirectoryWatcher.js). The followSymlinks option is always set to false which causes an issue with file watching when webpack is set to resolve symlinks. If it is manually set to true in this scenario, the watching works. Ideally this option would be configurable.

the version of [email protected] install failed on mac

node:v12.6.0

npm WARN deprecated [email protected]: Way too old

[email protected] install /usr/local/lib/node_modules/fsevents
node install

node-pre-gyp ERR! Tried to download(404): https://fsevents-binaries.s3-us-west-2.amazonaws.com/v1.2.3/fse-v1.2.3-node-v72-darwin-x64.tar.gz
node-pre-gyp ERR! Pre-built binaries not found for [email protected] and [email protected] (node-v72 ABI, unknown) (falling back to source compile with node-gyp)

[Security Vulnerability] watchpack has an insecure dependency

An npm audit triggered this notification when I updated today:

  High            Prototype Pollution

  Package         set-value

  Patched in      >=3.0.1

  Dependency of   @symfony/webpack-encore [dev]

  Path            @symfony/webpack-encore > webpack > watchpack > chokidar >
                  anymatch > micromatch > snapdragon > base > cache-base >
                  set-value

  More info       https://npmjs.com/advisories/1012

You can check the advisory here

In accordance to this, it appears this issue has already been patched.

Can we get a proper update for this pushed out?

Its causing havoc for those of us who are beholden to our bosses who only see the audit output in the CI with no other context 😆

Watch Mode stops functioning if emitted file is busy or locked

Do you want to request a feature or report a bug?
A bug

What is the current behavior?
When in watch mode, if a file is busy when attempting to emit to it, watch stops functioning. The following error is appropriately logged:

Error: EBUSY: resource busy or locked, open '..\js\bundle.js'
    at Error (native)

If the current behavior is a bug, please provide the steps to reproduce.
run webpack --watch
save a watched file
output to a file which is currently being used by another process

What is the expected behavior?
An error is logged to the console but watch mode continues to function. This is the behavior of Grunt and Gulp watchers.

Please mention other relevant information such as the browser version, Node.js version, Operating System and programming language.
A valid reason why a file could be momentarily busy is if it is being synced to a server directory.

--

Here are the details of my setup:

  • webpack version: 2.1.0-beta.25
  • node version: 6.9.1
  • os: windows 10
  • browser: chrome 55

--

Moved from webpack/webpack#3523

large symlinked module causes a hard FSEvents failure when using contexts

I’ve run into a fairly strange, fairly specific problem when running webpack in watch mode on OS X. When using require.context in the presence of a module with a lot of dependencies in node_modules that was symlinked using npm link, webpack seems to open a lot of file descriptors, very quickly leading to a rapid stream of dozens of errors per second coming from OS X’s FSEvents framework:

2016-04-18 11:21 node[34856] (FSEvents.framework) FSEventStreamRelease(): failed assertion 'streamRef != NULL'
2016-04-18 11:21 node[34856] (FSEvents.framework) FSEventStreamRelease(): failed assertion 'streamRef != NULL'
2016-04-18 11:21 node[34856] (FSEvents.framework) FSEventStreamCreate: _FSEventStreamCreate: ERROR: could not open kqueue
2016-04-18 11:21 node[34856] (FSEvents.framework) FSEventStreamScheduleWithRunLoop(): failed assertion 'streamRef != NULL'
2016-04-18 11:21 node[34856] (FSEvents.framework) FSEventStreamStart(): failed assertion 'streamRef != NULL'

This issue is similar to #1743, but I am not sure that it is actually the same, since that appears to be resolved with a chokidar fix, but I am using the latest version of chokidar and still get the error.

Steps to reproduce

Since this is such a specific problem, I’ve managed to reduce it to a pretty tiny, reproducible example, which you can find at lexi-lambda/webpack-fsevents-bug. Here’s some information about my environment as well:

operating system: OS X 10.11.3
node version: v5.10.1
npm version: 3.8.3

Here’s how to reproduce the issue:

  1. Clone https://github.com/lexi-lambda/webpack-fsevents-bug somewhere.
  2. Enter the linking-test directory and run npm install, then npm link.
  3. Enter the main directory and run npm install, then npm link linking-test.
  4. Run npm run watch.
  5. After a few seconds, you should start seeing the FSEvents errors.

More details

The issue seems to specifically be related to how running webpack in watch mode interacts with require.context. If you look in the single module in the whole project, you’ll see the following two lines:

var context = require.context('..', false, /config\.json$/);
console.log(context.keys());

I’ve explicitly passed false to require.context, but for some reason the placement of the linked package in the node_modules subdirectory clearly affects how webpack handles this context. The error does not occur without the custom context.

I have no idea if this has anything to do with a symlinked module specifically, and it’s certainly not that simple, because it doesn’t happen if the symlinked module does not have very many dependencies. However, with a lot of dependencies, like the ones I’ve included in my sample repo, it consistently fails. It might just be caused by having a lot of files/subdirectories and have nothing to do with the symlinking—I don’t know.

Either way, this is a pretty hard failure that is consistently reproducible, even on different machines, and I’ve been running into it repeatedly with a particular project I’m working on. Thank you for making webpack, it’s a wonderful tool! And let me know if there’s any more information I can provide to help.

Moved from webpack/webpack#2356

[Feature request] Config for only watching some of the events

Currently, we are watching all the events:

this.watcher.on("add", this.onFileAdded.bind(this));
this.watcher.on("addDir", this.onDirectoryAdded.bind(this));
this.watcher.on("change", this.onChange.bind(this));
this.watcher.on("unlink", this.onFileUnlinked.bind(this));
this.watcher.on("unlinkDir", this.onDirectoryUnlinked.bind(this));
this.watcher.on("error", this.onWatcherError.bind(this));

In our case (vuejs/vuepress#351), we only want webpack to watch change events, and other events will be handled by ourselves.

Files created right before watching starts make watching go into a loop

I've noticed this strange behaviour where watcher loops for 10 seconds due to this code:

if(data) {
  var ts = data[0] === data[1] ? data[0] + FS_ACCURENCY : data[0];
  if(ts > startTime)
    watcher.emit("change", data[1] + FS_ACCURENCY);
}

if(data) {
var ts = data[0] === data[1] ? data[0] + FS_ACCURENCY : data[0];
if(ts > startTime)
watcher.emit("change", data[1] + FS_ACCURENCY);

What I'm doing in my script is basically creating a file in a temporary directory /temp/entry.js, creating a webpack compiler and run compiler.watch(). Now for 10 seconds (which is the default value of FS_ACCURENCY) this is what's happening:

  • compilation succeeds
  • Watching.prototype._done gets called
  • recalling Watching.prototype.watch
  • which immediately triggers a change event for the /temp/entry.js file, because it's < 10 seconds old
  • back to step 1

Any pointers on how to fix this would be helpful. For example, this could be fixed by modifying the above code to this, but I'd need to stare at this for longer to understand what this block of code is conceptually responsible for.

if(ts > startTime + FS_ACCURENCY) {

npm test fails on OSX

ProductName: Mac OS X
ProductVersion: 10.10.4
BuildVersion: 14E17e

curiosity:watchpack gajus$ npm test

> [email protected] pretest /Users/gajus/watchpack
> npm run lint


> [email protected] lint /Users/gajus/watchpack
> eslint lib


> [email protected] test /Users/gajus/watchpack
> mocha



  DirectoryWatcher
    ✓ should detect a file creation (131ms)
    ✓ should detect a file change (187ms)
    ✓ should not detect a file change in initial scan (207ms)
    ✓ should detect a file change in initial scan with start date (2006ms)
    ✓ should not detect a file change in initial scan without start date (204ms)
    ✓ should detect multiple file changes (slow) (7014ms)
    ✓ should detect multiple file changes (fast) (2528ms)

  Watchpack
    ✓ should watch a single file (1118ms)
    ✓ should watch multiple files (1552ms)
    ✓ should watch a directory (1252ms)
    1) should watch a file than a directory
    2) "after each" hook

  10 passing (25s)
  2 failing

  1) Watchpack should watch a file than a directory:

      Uncaught expected [
  '/Users/gajus/watchpack/test/fixtures/dir/a',
  '/Users/gajus/watchpack/test/fixtures/dir'
] to equal [ '/Users/gajus/watchpack/test/fixtures/dir' ] (at length, A has 2 and B has 1)
      + expected - actual

       [
      -  "/Users/gajus/watchpack/test/fixtures/dir/a"
         "/Users/gajus/watchpack/test/fixtures/dir"
       ]

  AssertionError: expected [
    'test/fixtures/dir/a',
    'test/fixtures/dir'
  ] to equal [ 'test/fixtures/dir' ] (at length, A has 2 and B has 1)
      at EventEmitter.<anonymous> (test/watchpack.js:116:22)
      at EventEmitter._onTimeout (lib/watchpack.js:121:7)

  2) Watchpack "after each" hook:

      Uncaught expected [
  '/Users/gajus/watchpack/test/fixtures/dir {}',
  '/Users/gajus/watchpack/test/fixtures {}',
  '/Users/gajus/watchpack/test/fixtures/dir/subdir {}'
] to equal [] (at length, A has 3 and B has 0)
      + expected - actual

      -[
      -  "/Users/gajus/watchpack/test/fixtures/dir {}"
      -  "/Users/gajus/watchpack/test/fixtures {}"
      -  "/Users/gajus/watchpack/test/fixtures/dir/subdir {}"
      -]
      +[]

  AssertionError: expected [
    'test/fixtures/dir {}',
    'test/fixtures {}',
    'test/fixtures/dir/subdir {}'
  ] to equal [] (at length, A has 3 and B has 0)
      at TestHelper.<anonymous> (test/helpers/TestHelper.js:31:59)
      at null._onTimeout (test/helpers/TestHelper.js:59:3)



npm ERR! Test failed.  See above for more details.

Dependencies (chokidar) Security Vulnerabilities

This package requires old version of 'chokidar' package that requires 'set-value' with old version (2.0.0) which has vulnerability issue

Updating this package to require the latest version of 'chokidar' will resolve the issue.

Thanks,
Michal.

Watch does not recover from (forced) build error

I try to use watcher to rebuild automatically but fail the builds when jscs or jshint on a source file fails.
This works only once. After the first rebuild that is triggered through changing a watched file, any further update on any of the watched files will be ignored. It seems that watcher does not recover from the build error enforced by failOnHint: true. If I turn off failOnHint the rebuild process works as expected (issues an error, but builds with errors), but this is not what I intend to do.

This is the relevant part of my webpack.config.js

module.exports = {
    target: 'web',
    cache: true,
    watch: true,
    jscs: {
        // enforce jscs-passing builds only
        emitErrors: true,
        failOnHint: true,
        // pass down these options to jscs
        preset: 'google',
        requireCamelCaseOrUpperCaseIdentifiers: 'ignoreProperties',
        validateIndentation: null
    },
    jshint: {
        // enforce jshint-passing builds only
        emitErrors: true,
        failOnHint: true,
        // pass down these options to jshint
        browser: true,
        browserify: true,
        bitwise: true,
        ....

Anybody having this issue, too? Or any hint on how to fix this? Using polling mode does not work, either.

fsevents is WARN!!!

why do not remove this..

npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.