fix(hmr): upgrade http-proxy

[posva]

Fix #2392
Upgrades http-proxy

Summary

What kind of change does this PR introduce? (check at least one)

• Bugfix
• Feature
• Code style update
• Refactor
• Docs
• Build-related changes
• Other, please describe:

If changing the UI of default theme, please provide the before/after screenshot:

Does this PR introduce a breaking change? (check one)

• Yes
• No

If yes, please describe the impact and migration path for existing applications:

The PR fulfills these requirements:

• When resolving a specific issue, it's referenced in the PR's title (e.g. fix #xxx[,#xxx], where "xxx" is the issue number)

You have tested in the following browsers: (Providing a detailed version will be better.)

• Chrome
• Firefox
• Safari
• Edge
• IE

If adding a new feature, the PR's description includes:

• A convincing reason for adding this feature
• Related documents have been updated
• Related tests have been updated

To avoid wasting your time, it's best to open a feature request issue first and wait for approval before working on it.

Other information:

[billyyyyy3320]

Could you tell me how to reproduce it? I can't reproduce the issue to test this PR.

[posva]

Sure, in a fresh project:

mkdir bug-vuepress
cd bug-vuepress
yarn init -y
yarn add vuepress --dev
mkdir docs
touch docs/README.md
yarn vuepress dev docs

Open the docs in the browser, change anything in the README.md file and you will see it doesn't update.

I tried locally by building vuepress with this change and linking it and it fixed the problem. That being said, I didn't find a reason in http-proxy's changelog that would help understanding what broke it in the first place...

[haoqunjiang]

I don't think it fixed that problem.

[haoqunjiang]

1. Upgrading yarn.lock in the project does not fix a bug in the userland.
2. As described, a linked vuepress dependency fixed the problem. It's because the lockfile in this project hasn't been updated in months, it does not have the newly-introduced broken dependency anyway.

---

The root problem is chokidar - I'm still trying to understand why chokidar v3 in watchpack breaks the functionality, but the problem lies there.

[billyyyyy3320]

1. Upgrading yarn.lock in the project does not fix a bug in the userland.
2. As described, a linked vuepress dependency fixed the problem. It's because the lockfile in this project hasn't been updated in months, it does not have the newly-introduced broken dependency anyway.

The root problem is chokidar - I'm still trying to understand why chokidar v3 in watchpack breaks the functionality, but the problem lies there.

Thanks for your detailed perspective.

You're right. After deleting yarn.lock file and running yarn to install dependencies, the problem still exists.

[haoqunjiang]

The bug is that chokidar used by vuepress and webpack resolves to different instances.

vuepress/packages/@vuepress/core/lib/node/dev/index.js

Lines 67 to 79 in c6a3cb5

	watchSourceFiles () {
	// watch add/remove of files
	this.pagesWatcher = chokidar.watch([
	'**/*.md',
	'.vuepress/components/**/*.vue'
	], {
	cwd: this.context.sourceDir,
	ignored: ['.vuepress/**/*.md', 'node_modules'],
	ignoreInitial: true
	})
	this.pagesWatcher.on('add', target => this.handleUpdate('add', target))
	this.pagesWatcher.on('unlink', target => this.handleUpdate('unlink', target))
	}

The implementation in vuepress was never correct. It didn't listen to change events. It's just that when webpack and vuepress use the same chokidar instance, the listener in webpack also reacts to the source files' change events, so hot reload happens to work. It's just that it happens to work when they both use the same instance of chokidar v2, though I'm not sure about why. Seems the watcher on the file's parent directory (injected by webpack) somehow got called.

[ulivz]

@sodatea

The implementation in vuepress was never correct, It didn't listen to change events.

No, since all the *.md will be processed as a dynamic component, e.g.

export default {
  "v-0c799b30": () => import("/.../@vuepress/core/lib/node/docs.fallback/README.md") 
}

all the md files will be included in the webpack compilation flow by default, we don't need watch it.

---

This issue is actually introduced by this commit from anymatch, with the refactoring of implementation, we'll get following changes:

• Before:

chokidar.watch.target: '/a'
chokidar.ignore: ['!/b'],
is target included: true

• After:

chokidar.watch.target: '/a'
chokidar.ignore: ['!/b'],
is target included: false

---

Closed as it was fixed by #2436.