fix: re-run build when config files are changed in watch mode

[fi3ework]

Description

fix #11916

Additional context

I left a TODO in the returned watcher variable, when the build function is re-runed, the watcher will be not be valid anymore. We need to add something like getWatcher: ()=> RollupWatcher(will be a breaking change) or use a global watcher ref to hold the reference. I'm not sure which is the better solution so I left a TODO there for code review. Anyway, with this PR, we could make the build re-run in cli.

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the PR Title Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[bluwy]

I think we should make the build() function receive a new parameter to enable this for now, to prevent breaking programmatic usage. I also think returning a () => RollupWatcher instead might be nice API-wise if the parameter is enabled. We might also need to use overloads to prevent breaking the types.

In Vite 5, we can enable this by default. (We can add a TODO for that for now)

[fi3ework]

Made some modifications

• the fix is enabled by default in cli mode
• pass watchConfig param to enable this in the programmatic API
• add a new ()=> RollupWatcher to the returned type of build, unsure if we need an overload to prevent the type breaking 🤔? Maybe we can run the /ecosystem-ci first to give it a try?

[fi3ework]

Feeling like we need to add some type test to prevent casual public API breaking 🤔.

[bluwy]

I was thinking we add this param to build() directly since it only needs to be controlled programatically. That way it's easier to create the type overload too.

[bluwy]

I think we need to use a weakmap of the builds resolvedConfig to RollupWatcher, so that multiple build watches don't conflict with this single variable.

[bluwy]

The env files needs to be resolved from config.envDir too, instead of process.cwd() with path.resolve.

[bluwy]

Maybe it would be nice to log that we're restarting because of config change, similar to

vite/packages/vite/src/node/server/hmr.ts

Lines 59 to 66 in 7110ddf

	// auto restart server
	debugHmr(`[config change] ${colors.dim(shortFile)}`)
	config.logger.info(
	colors.green(
	`${path.relative(process.cwd(), file)} changed, restarting server...`,
	),
	{ clear: true, timestamp: true },
	)

[bluwy]

• add a new ()=> RollupWatcher to the returned type of build, unsure if we need an overload to prevent the type breaking 🤔? Maybe we can run the /ecosystem-ci first to give it a try?

With the current PR, I think it would break since it returns a function-type regardless if ecosystem-ci passes, so it would be nice to avoid that with overloads.

Feeling like we need to add some type test to prevent casual public API breaking 🤔.

Yes that would be great too. We have a bit of types test currently at

vite/packages/vite/package.json

Line 61 in 7110ddf

"build-types-check": "tsx scripts/checkBuiltTypes.ts && tsc --project tsconfig.check.json",