Only one HostsResolver per hosts file

[szmarczak]

Fixes #25

[szmarczak]

@dylang What do you think about this?

[dylang]

Thanks for your quick attention this. This does not solve the memory issue, at least not in Jest. I'll try to dig deeper later, I can't right now.

[dylang]

I think it doesn't solve the problem in this part of the code:

this._promise = (async () => {
			if (typeof this._hostsPath !== 'string') {
				return;
			}

			await this._update();

			if (this._error) {
				return;
			}

			watchFile(this._hostsPath, {
				persistent: false
			}, (current, previous) => {
				if (current.mtime > previous.mtime) {
					this._update();
				}
			}).once('error', error => {
				this._error = error;
				this._hosts = {};
			});

			this._promise = null;
		})();

Can watchFile be opt-in instead of opt-out?

What stops watchFile?

[szmarczak]

What stops watchFile?

Simply pass dnsCache: new CacheableLookup({customHostsPath: false}) or dnsCache: false.

[szmarczak]

Can watchFile be opt-in instead of opt-out?

Yep, will do this tomorrow.

[dylang]

Simply pass dnsCache: new CacheableLookup({customHostsPath: false}) or dnsCache: false.

That prevents it, but once watchFile starts watching, what will stop it from watching, other than killing the process?

Also, unrelated, using fs.watch() is more efficient than fs.watchFile()
https://nodejs.org/docs/latest/api/fs.html#fs_fs_watch_filename_options_listener

[szmarczak]

what will stop it from watching, other than killing the process?

Unfortunately there are no destructors in JS.
That's why I implemented in this PR some sort of singletons.

Also, unrelated, using fs.watch() is more efficient than fs.watchFile()

Thanks, didn't know that! But this doesn't fix the memory leak either, does it?

[dylang]

Unfortunately there are no destructors in JS.

Correct. This is why it might be better to export a method to start and stop the watcher.