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
First, thank you for the excellent project. I was looking an HMR solution for extension development, stumbled on this one, and have been very pleased with the results. Much appreciated.
Summary
Ideally, the additionalInputs option would:
Handle files outside of the extension root directory
Handle globs for files referenced in additionalInputs
Support options similar to copy-related plugins like rollup-plugin-copy or vite-plugin-static-copy (which is based on the former plugin) to set the file destination within /dist, flatten directories, rename files, etc.
Use Case
I have a monorepo containing an extension generated by this project stored in an /extension directory. The extension requires files accessed via the parent directory. For example, I'd like to include files from /files directory in the directory structure below:
I hoped I could use the additionalInputs option to watch/copy these files to /dist, add them to the web_accessible_resources section in manifest.json automatically, and have that work for both a build and development using HMR:
Unfortunately, using paths outside of the extension root results in the following error:
Invalid substitution "../files/file" for placeholder "[name]" in "output.entryFileNames" pattern, can be neither absolute nor relative path.
I've tried several other approaches to using files outside of the extension root, but they all have issues:
File are copied but not automatically referenced in under web_accessible_resources in manifest.json.
Files are copied but not watched
Files are copied but not detected by webExtension plugin hook (copy happens after webExtension)
Files copied to /extension/src create unwanted duplicates outside of /dist directory
File copying and manifest.json updates work properly when I build but not during development with HMR.
I can cobble a solution together, but it will be a much less elegant since the additionalInputs option does exactly what I need except it currently does not work with files outside of the extension root.
Proposed Enhancements
Given the same directory structure shown above, I'd like to use a glob pattern to reference all of the files in the /files directory:
If options similar to the ones found in rollup-plugin-copy or vite-plugin-static-copy were added, the additionalInputs configuration could look something like this:
I'm somewhat in favor of handling files outside of the root directory, but I'd want to double check what Vite's stance on something like that is. I don't think you're normally able to import/pull files outside of the root of the project (or its dependencies) for security reasons, but I could be wrong.
I'd agree with supporting glob patterns for additionalInputs. Though your expected web_accessible_resources are more likely to be the parsed glob inputs as opposed to carrying over the glob pattern itself since the pattern syntax will probably be different than what web_accessible_resource supports. With the plugin's optimizeWebAccessibleResources option they should still end up combined into a single entry, though.
Instead of this, I'd rather ensure that existing vite/rollup options for modifying output filenames (rollupOptions.output.assetFileNames, rollupOptions.output.chunkFileNames, rollupOptions.output.entryFileNames) fully work if they aren't already. additionInputs are treated as rollup inputs, so those should be being applied to them.
One clarification worth making is that the files I'd like to include outside of the web extension root (the "external" files) are static files. Specifically, these files are loaded via dynamic import so there are no static imports referencing files outside of the extension root for Vite to trip on while bundling. The goal is to just make the files available to the extension like other web_accessible_resources files (i.e., watch the files, copy (build) or update (dev) when a change is detected, and modify the manifest accordingly).
I realize this doesn't cover every possible scenario that involves files outside of the extension root, but I thought it was worth clarifying in case it simplifies to problem.
First, thank you for the excellent project. I was looking an HMR solution for extension development, stumbled on this one, and have been very pleased with the results. Much appreciated.
Summary
Ideally, the
additionalInputs
option would:additionalInputs
/dist
, flatten directories, rename files, etc.Use Case
I have a monorepo containing an extension generated by this project stored in an
/extension
directory. The extension requires files accessed via the parent directory. For example, I'd like to include files from/files
directory in the directory structure below:I hoped I could use the
additionalInputs
option to watch/copy these files to/dist
, add them to theweb_accessible_resources
section inmanifest.json
automatically, and have that work for both a build and development using HMR:Unfortunately, using paths outside of the extension root results in the following error:
I've tried several other approaches to using files outside of the extension root, but they all have issues:
web_accessible_resources
inmanifest.json
.webExtension
plugin hook (copy happens afterwebExtension
)/extension/src
create unwanted duplicates outside of/dist
directorymanifest.json
updates work properly when Ibuild
but not during development with HMR.I can cobble a solution together, but it will be a much less elegant since the
additionalInputs
option does exactly what I need except it currently does not work with files outside of the extension root.Proposed Enhancements
Given the same directory structure shown above, I'd like to use a glob pattern to reference all of the files in the
/files
directory:This would expect this to produce the following:
If options similar to the ones found in rollup-plugin-copy or vite-plugin-static-copy were added, the
additionalInputs
configuration could look something like this:Thanks in advance for your consideration. I'm happy discuss in more detail and contribute to the effort if you believe this would be worth doing.
The text was updated successfully, but these errors were encountered: