The importing statements injected by Vite Plugin cause unnecessary dependencies resolving overhead

[zheeeng]

Describe the bug

The importing statements injected by Vite Plugin cause unnecessary dependencies resolving overhead.

If a plugin injects importing statements into an application, there are two flaws:

1. The pre-bunding discovery will skip the scanning of the content of importing statements at the startup phase.
2. Dependencies discovery will be triggered asynchronously.

I'm developing a huge application that needs the dependencies injection.

I'm using a Vite plugin to scan the whole project and find out injectable content, using async importing statements injecting them into a provider container(IOC).

The plugin works well but the application startup speed is horrible at the first time (or without .vite bundle cache), almost 10+ mins(vs 1 min before the migrating from Webpack), I think it is mainly caused by the second flaw.

This demo plugin is as simple as

{
      name: 'vite-inject-importing-statements',
      load(id) {
        if (!id.includes('bootstrap')) {
          return
        }
        
        return fs.readFileSync(id, 'utf-8').replace(
          'Promise.all([])',
          `
          Promise.all([
            import('./pixi'),
          ])
          `
        )
      }
    }

replace the file content from const modules: any[] = await Promise.all([]) to const modules: any[] = await Promise.all([import('./pixi')]).

If without the plugin, write the replacement directly, console reports:

It's extremely fast.

Once the plugin worked, console reports:

At a large-scale application, the console reports many times for the newly founded dependencies and repeatedly reloads the page, it takes too long to start up an application without the building cache.

No matter whether it's using dynamic importing to static importing statements, the buggy case will be reproduced stably.

I tried another experiment for writing down import statements manually and enabling the plugin to rewrites the same statements, Vite handles the case very well without repeatedly re-discovery dependencies.

There is also a minimum reproduction below.

Happy lunar new year. 🎉🎉🎉

Reproduction

https://github.com/zheeeng/vite-inject-importing-statemetns

System Info

System:
    OS: macOS 11.5.2
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
    Memory: 77.42 MB / 16.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 14.18.1 - ~/.nvm/versions/node/v14.17.0/bin/node
    Yarn: 1.22.11 - ~/.nvm/versions/node/v14.17.0/bin/yarn
    npm: 6.14.15 - ~/.nvm/versions/node/v14.17.0/bin/npm
  Browsers:
    Chrome: 97.0.4692.99
    Safari: 14.1.2
  npmPackages:
    vite: ^2.7.13 => 2.7.13

Used Package Manager

pnpm

Logs

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/core instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[zheeeng]

Another buggy behavior is the sourcemap file resolving fail:

1. Sourcemap for the third party modules. e.g. Sourcemap for "/Users/zheeeng/Workspace/vvfx-new/node_modules/.pnpm/inversify@5.1.1/node_modules/inversify/lib/inversify.js" points to missing source files
2. Sourcemap for chunked js file under .vite. e.g. 下午10:54:23 [vite] Failed to load source map for /node_modules/.vite/chunk-WT4RPIXK.js?v=7b399ea9.
3. Sourcemap for cached module file under .vite. e.g. 上午10:54:23 [vite] Failed to load source map for /node_modules/.vite/@vvfx_shared_node_modules_antd_es_message.js?v=8993e4f2.