Disable specific chunks or preload-helper

[onordgren]

Hello! This is kind two questions in one. Is it possible to prevent a certain chunk from being generated and force it to be inlined into the script importing it? If not, is it possible to control this behaviour for the preload-helper?

The reason I'm asking is that I'm currently using vite to build a couple of entry files. These entry files are included with a non module script that so I would like them to be import free. After adding a second entry file I however noticed that Vite chunked the preload-helper and added an import instead of inlining it.

[r-r-lima]

Hey @onordgren!
I'm facing a similar issue, did you ever find a solution for your case?
Appreciated!

[liamvdv]

@onordgren @r-r-lima
Hey, I have an idiomatic solution.

1. You can explicitly import the preload module in your entrypoint. Rebuild and you will see that the preload-helper-xxxx.js will now be named ./modulepreload-polyfill-xxxxx.js and in the chunk be referenced as import {_ as o} from ./modulepreload-polyfill-xxxxx.js. See docs here as to why.

// src/loader.ts
import "vite/modulepreload-polyfill";

3. You can then explicitly control the module inlining with rollup. Let's name the group 'loader' and control via manualChunks in you vite.config.ts:

export default defineConfig({
// ...
build: {
    rollupOptions: {
      input: {
        loader: "src/loader.ts",
      },
      output: {
          manualChunks(id) {
          if (id.includes("loader")) {
            return "loader";
          }
          // NOTE(liamvdv): requries manual import in loader.ts
          if (id.includes("modulepreload-polyfill")) {
            return "loader";
          }
          // default naming
          return undefined;
        },
      },
    },
  },
 })

Usually you are aiming to inline the script if your script is loaded on another domain, in which case ./some-dynamic-import will refer not to where-my-assets-lie.com/some-dynamic-import but instead somecustomer.com/seom-dynamic-import, which will 404.
In this case, you can explicitly set the base config option to your target domain,

// ./vite.config.ts
export default defineConfig({
     base: "https://where-my-assets-lie.com/"
     // ...
})

[onordgren]

Hey @liamvdv - are you sure that the preload-helper and the modulepreload-polyfill are the same things? I tried to import it in my entry file but the result was that it imported both of them, see below.

import{_ as e}from"../../preload-helper-D7HrI6pR.js";import"../../modulepreload-polyfill-B5Qt9EMX.js";...

[liamvdv]

Hm, interesting. I think it is the same thing. The issue you face is that it is still not inlined into your chunk. Please use manual Chunking to enforce a single rendered chunk.
(Note: If you have multiple entrypoints, vite optimizes globally and this can sometimes lead to difficulty inlining shared code, i.e. I assume you need the helper also elsewhere, thats why its an external module (not inlined).)

Please first try to inline the helper via manualChunking.

Report back if it worked 🤗

[liamvdv]

In my experience, getting the controls right when building for multiple use cases / entrypoints is difficult (e.g. a standalone and a widget loader script with dynamic imports).
Just use 2 vite configs and use --config to target different configs. Rewrite your npm run build to run both using &&.
Make sure that build.emptyOutDir is false or rewrite your out dirs to ensure the consecutive builds don't interfere with each other. Overwriting files is less of an issue, given that hashes are suffixed and reduce the likelyhood of a collision of files with different content.

[onordgren]

Thx for your response @liamvdv , I also tried to do the manual chunk and return the same value as my entry but it would just create a loader2.js next to loader.js.

Yea been investigating other alternatives as I think our use case might not be a perfect fit for Vite. We need to be able to have multiple javascript and HTML entries and ideally be able to configure them accordingly. Being able to for example inline imports automatically in the entry files would also be nice. The custom inline plugin works but it can break in case any of the root properties in the preload-helper collides with a property in the entry etc.

Never tried the multiple config setup before. I assume Vite won't be able to optimize the chunks between the configs then? For example, we have vendor deps and translations that can/should be shared between the entries to improve load times.