Replies: 2 comments 1 reply
-
|
A thought I had over the weekend: Why not just call the builtin Vite plugin and check the result? Something like: async load(id) {
const viteAsset = config.plugins.find(x => x.name === 'vite:asset')
const asset = await viteAsset?.load?.call(this, id)
if (typeof asset === 'string' && asset.startsWith('export default')) {
console.log(asset)
return asset.replace(/[A-Z]:/i, "")
}
return asset
}I quickly threw something together and it seems to work alright. Would need to be more robust to account for some edge cases. I'm not sure what the ramifications are for calling this plugin out of its usual order. |
Beta Was this translation helpful? Give feedback.
-
|
@kaylynb Really promising idea! 🤯 |
Beta Was this translation helpful? Give feedback.
-
|
One additional problem is that using the full path name on Windows might easily hit the max path length. This isn't an issue for the normal vite dev server since it's not writing an actual file to resolve. May need additional special handling in this area to keep the length similar to a dependency path. I will have a better idea when I get time to setup a Windows instance and do a real impl. |
Beta Was this translation helpful? Give feedback.
-
Hi! I'm wondering if anyone has ideas for importing assets from another package when
node_modulesis hoisted. Ran into this problem while converting a large web app over to Vite and @crxjs/vite-plugin. Even if the package isn't from the workspace,npmwill hoistnode_modulesto the root of a monorepo. Maybe this is a bug/feature request but I'm not sure this is supposed to work and/or even can work with the way Vite handles asset imports.For example, using
npmworkspaces:The relative path to the asset will be outside the root of the
chrome-extproject.Here's a simple reproduction of the issue: https://github.com/kaylynb/crxjs_vite_workspace_import_asset
If
chrome-extattempts to import an asset frommain, it won't be able to:Vitewill rewrite the path to/@fs/some/absolute/path/asset.svgwhich in a normal app the static server will resolve when a request is made.Building actually works fine on Linux and Windows without doing anything. It's just dev mode that doesn't work.
Possible Workarounds
preserveSymlinkshttps://vitejs.dev/config/#resolve-preservesymlinks
This doesn't actually work for a typical
npmworkspace as everything is hoisted into the rootnode_modules, but it works if just using a symlink.pnpmis close to working here since it creates anode_modulesdirectory for each package in a workspace instead of hoisting. But the special strict dependency tree doesn't work withpreserveSymlinks.Consolidate assets into a package and use a
postinstallhook to copy to localnode_modules.This seems like it may be the easiest solution despite it being a bit of a hack.
Changing
crxjs@vite-pluginGetting this to 'just work' would be nice as there would be no need to worry about
npmvspnpmvs whatever other tooling. I've tried to see if I can get it working with a few changes.See: main...kaylynb:external_asset_load
Changing this line:
https://github.com/crxjs/rollup-plugin-chrome-extension/blob/2fa0dfb1476ff3db44a1458e4be3661eaf6f872c/packages/vite-plugin/src/node/plugin-fileWriter--chunks.ts#L42
and removing the filter for
@fsallows it to get past this error.But then
Rolluphas an error since it can't callemitFilewith a path outside its root:https://github.com/crxjs/rollup-plugin-chrome-extension/blob/2fa0dfb1476ff3db44a1458e4be3661eaf6f872c/packages/vite-plugin/src/node/plugin-fileWriter--chunks.ts#L143-L147
The
@fspath can be emitted instead and actually matches whatViteoutputs into the[asset].jsfile:This actually seems to work well although I'm not that familiar with Rollup or Vite so am unaware what else it might break. Just started digging into the internals in the last week or so.
Does not work on Windows.
Vite exports the full path into the
[asset].jsfile when loading:https://github.com/vitejs/vite/blob/a5bdb9fa706850c45134c25b77aea2dee1ea03d4/packages/vite/src/node/plugins/asset.ts#L80
Which on Windows will be something like
/@fs/C:/some/full/path/asset.svgThen in the static file middleware from the server it removes the
/@fs/C:part:https://github.com/vitejs/vite/blob/a5bdb9fa706850c45134c25b77aea2dee1ea03d4/packages/vite/src/node/server/middlewares/static.ts#L132-L133
Problem is,
@crxjs/vite-pluginwith the fixes just uses this URL as the file path to write intodist, but@fs/C:/some/full/path/asset.pngis not a valid path on Windows. Even if the invalid part is stripped out and the file is written, it won't be found in the chrome extension becauseVitepreviously emitted the export in the[asset].jsto the invalid Windows path.I'm a bit stuck here since changing how Vite itself emits the asset file is possible, but I think would require re-implementing a lot of the other things the asset loader does. At least that's what I think given my limited understanding of the plugin system.
Beta Was this translation helpful? Give feedback.
All reactions