fix: handle optimize failure

[bluwy]

Description

Stop optimize reload if fail on esbuild bundling.

Additional context

Looking into #3715 today. With Vite 2.9, when optimization fails (because of named importing a nodejs module, will also look into this soon), vite would reload optimization again, but since it would always fail, it will reload infinitely.

Question: Should we not do a fullReload all together?

Note: I also made a repro https://github.com/bluwy/vite-bundle-node-issue

---

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 Commit 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.

[patak-dev]

You are on fire today 🔥

I didn't modify this in the last batch of deps optimization PRs. This was always full reloading on error before: https://github.com/vitejs/vite/blame/b214115bffd07c5baca9da36d3b3608007d00920/packages/vite/src/node/optimizer/registerMissing.ts#L86. But I added a reset that is triggering the re-discovery of deps:

      // Reset missing deps, let the server rediscover the dependencies
      metadata.discovered = {}

I don't know if this reset is helping actually. But given that the user may edit files and fix a potential issue by deleting a dep import, it may avoid a full reload.

I vote to avoid full-reload altogether when there is an error, and maybe we could add a better warning stating that this is an internal error and the user may need to restart the server? I don't think we can recover from this situation.

[bluwy]

It was a public holiday yesterday 😄

Yeah it looks like the reset plays a factor too. I think the reset helps that if I comment/uncomment the problematic import, the dev server is able to recover and work properly again, using the repro.

I think removing the fullReload make sense. If it fails once, it's likely to fail the same way twice. I don't think it's necessarily an internal error though, there could be libraries that are incorrectly bundled that messes up esbuild, so maybe we can leave the error as is.