 导入同目录资源？)
Vite 中如何用 new URL(url, import.meta.url) 导入同目录资源【免费下载链接】viteNext generation frontend tooling. Its fast!项目地址: https://gitcode.com/GitHub_Trending/vi/vite当你想在 JS 里引用同目录或相对目录下的静态资源又不想先写一条import语句、或者路径是运行时才能确定的变量时Vite 支持用原生的new URL(url, import.meta.url)写法直接拿到资源在浏览器中的完整 URL。import.meta.url是 ESM 的原生特性暴露当前模块的 URL配合原生URL构造函数就能从 JS 模块里按相对路径解析出静态资源的完整地址。这个写法要求目标浏览器原生支持 ESM即支持import.meta.url。基本用法静态路径资源放在 JS 模块的相对路径下直接写成const imgUrl new URL(./img.png, import.meta.url).href document.getElementById(hero-img).src imgUrl开发阶段这个写法在现代浏览器里是原生生效的——Vite 甚至不需要处理这段代码浏览器自己就能把相对路径解析成当前模块下的资源地址然后正常加载img.png。动态路径模板字符串路径由变量拼出来时同样可以用模板字符串function getImageUrl(name) { // note that this does not include files in subdirectories return new URL(./dir/${name}.png, import.meta.url).href }注意文档给出的限制这种动态写法不会覆盖子目录中的文件只能匹配模板里列出的那一级目录。生产构建时 Vite 做了什么生产构建时Vite 会对这类代码做必要转换让 URL 在打包和资源文件名加 hash 之后仍然指向正确位置。但前提是URL 字符串必须是静态的这样 Vite 才能分析出引用了哪些文件。分析不了的写法会被原样保留如果build.target不支持import.meta.url就可能引发运行时错误// Vite will not transform this const imgUrl new URL(imagePath, import.meta.url).href对于上面getImageUrl这种可静态分析的动态写法Vite 会把它改写成先逐个import目录中匹配到的文件再用一张查找表取 URL文档给出的转换结果示例import __img0png from ./dir/img0.png import __img1png from ./dir/img1.png function getImageUrl(name) { const modules { ./dir/img0.png: __img0png, ./dir/img1.png: __img1png, } return new URL(modules[./dir/${name}.png], import.meta.url).href }也就是说动态写法能解析到哪些文件取决于构建时 Vite 能静态枚举出的文件集合运行时传入一个不在集合里的文件名modules[...]取不到值拿到的 URL 就会无效。如何判断写法是否生效开发阶段浏览器原生解析不需要 Vite 参与。页面上img的src应指向开发服务器下该资源的路径资源能正常显示即说明工作正常。生产构建后检查产物中该资源是否被加 hash 的assets文件替代且new URL(...).href指向的就是这个文件——文档说明 Vite 的转换就是为了保证打包和 hash 之后 URL 仍指向正确位置。URL 不是静态字符串如imagePath变量Vite 不转换代码按原样输出此时若build.target不支持import.meta.url会在运行时出错。build.target默认值是baseline-widely-available当前主版本对应[chrome111, edge111, firefox114, safari16.4, ios16.4]详见 Build Options。构建时如果代码含有 Oxc 无法安全转译的特性构建会输出警告。限制与边界以下情况来自文档的明确说明使用这个写法前需要核对不适用于 SSR。import.meta.url在浏览器和 Node.js 中的语义不同服务端 bundle 也无法预先确定客户端的主机 URL所以 Vite 做 Server-Side Rendering 时这个模式不工作。UMD / IIFE 输出格式import.meta.url不再被 polyfill默认会被替换为undefined。如果依赖旧行为可以用define配置项配合build.rolldownOptions.output.intro处理见 migration 文档。相对base也依赖import.meta把base设为./或时所有生成的 URL 都是相对每个文件的这需要浏览器支持import.meta要兼容不支持的旧浏览器可以使用 legacy 插件见 Public Base Path。需要部署到嵌套公共路径下时指定base配置项或vite build --base/my/public/path/即可资源路径会在构建时相应改写运行时动态拼接 URL 的场景可改用全局注入的import.meta.env.BASE_URL必须原样出现import.meta.env[BASE_URL]这种写法不会生效。相关场景Worker 入口同一个写法也是文档推荐的创建 Web Worker 的方式——new URL()必须直接出现在new Worker()声明内部才会被识别为 worker否则按普通静态资产 URL 处理const worker new Worker(new URL(./worker.js, import.meta.url))Worker 构造函数的选项也必须是静态值字符串字面量例如创建 module worker 时写{ type: module }。更多细节见 Web Workers 章节。完整的资产处理规则?url、?raw、?inline后缀、public目录等在 Static Asset Handling 中。【免费下载链接】viteNext generation frontend tooling. Its fast!项目地址: https://gitcode.com/GitHub_Trending/vi/vite创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Vite 中如何用 new URL(url, import.meta.url) 导入同目录资源？
Vite 中如何用 new URL(url, import.meta.url) 导入同目录资源【免费下载链接】viteNext generation frontend tooling. Its fast!项目地址: https://gitcode.com/GitHub_Trending/vi/vite当你想在 JS 里引用同目录或相对目录下的静态资源又不想先写一条import语句、或者路径是运行时才能确定的变量时Vite 支持用原生的new URL(url, import.meta.url)写法直接拿到资源在浏览器中的完整 URL。import.meta.url是 ESM 的原生特性暴露当前模块的 URL配合原生URL构造函数就能从 JS 模块里按相对路径解析出静态资源的完整地址。这个写法要求目标浏览器原生支持 ESM即支持import.meta.url。基本用法静态路径资源放在 JS 模块的相对路径下直接写成const imgUrl new URL(./img.png, import.meta.url).href document.getElementById(hero-img).src imgUrl开发阶段这个写法在现代浏览器里是原生生效的——Vite 甚至不需要处理这段代码浏览器自己就能把相对路径解析成当前模块下的资源地址然后正常加载img.png。动态路径模板字符串路径由变量拼出来时同样可以用模板字符串function getImageUrl(name) { // note that this does not include files in subdirectories return new URL(./dir/${name}.png, import.meta.url).href }注意文档给出的限制这种动态写法不会覆盖子目录中的文件只能匹配模板里列出的那一级目录。生产构建时 Vite 做了什么生产构建时Vite 会对这类代码做必要转换让 URL 在打包和资源文件名加 hash 之后仍然指向正确位置。但前提是URL 字符串必须是静态的这样 Vite 才能分析出引用了哪些文件。分析不了的写法会被原样保留如果build.target不支持import.meta.url就可能引发运行时错误// Vite will not transform this const imgUrl new URL(imagePath, import.meta.url).href对于上面getImageUrl这种可静态分析的动态写法Vite 会把它改写成先逐个import目录中匹配到的文件再用一张查找表取 URL文档给出的转换结果示例import __img0png from ./dir/img0.png import __img1png from ./dir/img1.png function getImageUrl(name) { const modules { ./dir/img0.png: __img0png, ./dir/img1.png: __img1png, } return new URL(modules[./dir/${name}.png], import.meta.url).href }也就是说动态写法能解析到哪些文件取决于构建时 Vite 能静态枚举出的文件集合运行时传入一个不在集合里的文件名modules[...]取不到值拿到的 URL 就会无效。如何判断写法是否生效开发阶段浏览器原生解析不需要 Vite 参与。页面上img的src应指向开发服务器下该资源的路径资源能正常显示即说明工作正常。生产构建后检查产物中该资源是否被加 hash 的assets文件替代且new URL(...).href指向的就是这个文件——文档说明 Vite 的转换就是为了保证打包和 hash 之后 URL 仍指向正确位置。URL 不是静态字符串如imagePath变量Vite 不转换代码按原样输出此时若build.target不支持import.meta.url会在运行时出错。build.target默认值是baseline-widely-available当前主版本对应[chrome111, edge111, firefox114, safari16.4, ios16.4]详见 Build Options。构建时如果代码含有 Oxc 无法安全转译的特性构建会输出警告。限制与边界以下情况来自文档的明确说明使用这个写法前需要核对不适用于 SSR。import.meta.url在浏览器和 Node.js 中的语义不同服务端 bundle 也无法预先确定客户端的主机 URL所以 Vite 做 Server-Side Rendering 时这个模式不工作。UMD / IIFE 输出格式import.meta.url不再被 polyfill默认会被替换为undefined。如果依赖旧行为可以用define配置项配合build.rolldownOptions.output.intro处理见 migration 文档。相对base也依赖import.meta把base设为./或时所有生成的 URL 都是相对每个文件的这需要浏览器支持import.meta要兼容不支持的旧浏览器可以使用 legacy 插件见 Public Base Path。需要部署到嵌套公共路径下时指定base配置项或vite build --base/my/public/path/即可资源路径会在构建时相应改写运行时动态拼接 URL 的场景可改用全局注入的import.meta.env.BASE_URL必须原样出现import.meta.env[BASE_URL]这种写法不会生效。相关场景Worker 入口同一个写法也是文档推荐的创建 Web Worker 的方式——new URL()必须直接出现在new Worker()声明内部才会被识别为 worker否则按普通静态资产 URL 处理const worker new Worker(new URL(./worker.js, import.meta.url))Worker 构造函数的选项也必须是静态值字符串字面量例如创建 module worker 时写{ type: module }。更多细节见 Web Workers 章节。完整的资产处理规则?url、?raw、?inline后缀、public目录等在 Static Asset Handling 中。【免费下载链接】viteNext generation frontend tooling. Its fast!项目地址: https://gitcode.com/GitHub_Trending/vi/vite创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
