You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While Vite is a great solution in the development side, it still uses Rollup instead of Esbuild in the production builds. I am trying to create custom build scripts that use Esbuild as much as possible to increase production build speed. While CSS could have been done outside this build process, Esbuild does use information of imports to bundle it as well, so I'm trying to make use of it.
During this bundling process, Esbuild now changes the filenames of these bundled CSS files into something that is not fully predictable, because of the breaking change introduced in #1293, and because you can use [hash] in the definition of the entryNames build option parameter.
I'm trying to create a index.html file that injects these entry points into the relevant points of the DOM. I can do it on the Js modules by looking at the result.metafile.outputs and searching for where the original entryPoint ended up in (doable, even though the key-values are a bit opposite of what is these kinds of analysis need).
But on the CSS outputs all the entryPoint properties are missing, even though Esbuild surely knows that they were caused by a certain entryPoint, either configured or that has been code-split.
This leaves me with no way to predict the CSS output filename in a general case. I can do it for a specific build but I cannot create a generic build script that reacts automatically to the output names and then injects the correct information into index.html. Besides this, I'm sure there are other use cases for this kind of information.
This is an example of the algorithm I'm trying to use to get this information (the paths are hardcoded for clarity sake):
letinjectList=[];Object.entries(result.metafile.outputs).forEach(([key,value])=>{if(value.entryPoint=='src/main.js'){constz=path.relative(distDir,key).replace(/\\/g,"/");console.log(z);injectList.push(z);}//Currently there is no entryPoint in the metafile that allows us to know what outputs // did the original js entries caused in terms of generated css outputs.//This makes it impossible to differentiate between css output entries unless we make// heavy-handed assumptions like this one. This fails immediately if we try to add a // hash suffix to the entryNames naming options.if(key.endsWith("main.css")){constz=path.relative(distDir,key).replace(/\\/g,"/");console.log(z);injectList.push(z);}});
The text was updated successfully, but these errors were encountered:
While Vite is a great solution in the development side, it still uses Rollup instead of Esbuild in the production builds. I am trying to create custom build scripts that use Esbuild as much as possible to increase production build speed. While CSS could have been done outside this build process, Esbuild does use information of imports to bundle it as well, so I'm trying to make use of it.
During this bundling process, Esbuild now changes the filenames of these bundled CSS files into something that is not fully predictable, because of the breaking change introduced in #1293, and because you can use
[hash]
in the definition of theentryNames
build option parameter.I'm trying to create a index.html file that injects these entry points into the relevant points of the DOM. I can do it on the Js modules by looking at the
result.metafile.outputs
and searching for where the original entryPoint ended up in (doable, even though the key-values are a bit opposite of what is these kinds of analysis need).But on the CSS outputs all the entryPoint properties are missing, even though Esbuild surely knows that they were caused by a certain entryPoint, either configured or that has been code-split.
This leaves me with no way to predict the CSS output filename in a general case. I can do it for a specific build but I cannot create a generic build script that reacts automatically to the output names and then injects the correct information into index.html. Besides this, I'm sure there are other use cases for this kind of information.
This is an example of the algorithm I'm trying to use to get this information (the paths are hardcoded for clarity sake):
The text was updated successfully, but these errors were encountered: