Respect import maps #2483
Comments
|
I think the better way to deal with this is to respect import maps when parsing Also, if you want to import from CDNS, you can use |
yyx990803
changed the title
|
It can be easily polyfilled with https://www.npmjs.com/package/es-module-shims though, but I agree Vite aliases might be better for production. But Vite respecting the import maps would be also great. |
|
For anyone interested in using importmaps with Vite right now, you can with workaround. When es-module-shims polyfill is used with |
|
@lubomirblazekcz I've tried the polyfill but it doesn't work with the dev server since the analyzer plugin throws an error: |
This is true, but it has the unfortunate side-effect that code inside a regular module script tag can't access code inside the importmap-shim script tag. Unless you've found a way that they can talk? |
|
Does anybody know if there's any progress on this? |
|
Does anyone know if there's any progress on this? |
|
I'm also interested in plans / potential progress / roadmap for this. |
|
We discussed this feature in a recent team meeting and we decided that the best path forward is:
Vite has a single module graph for its server. If you have two modules imported by different HTML entry points, they will be a single module node in graph. Vite could automatically read the import map and respect it without |
|
I'm also encountering same issue to workaround (for EX: in my case, i'd like to external react/react-dom)
|
|
I have created a plugin to solve this issue during development, until official support is implemented: https://github.com/MilanKovacic/vite-plugin-externalize-dependencies |
Hi @patak-dev, any progress on this? |
@MilanKovacic thanks for your plugin but seems not work, as @vctqs1 said it will broken in dev mode, since vite still resolve react/jsx-dev-runtime. |
Hi, it works in development mode, you just have to specify all of the exports, for example: ["react", "react-dom", "react-dom/client", "react/jsx-runtime", "react/jsx-dev-runtime"]. This will not be necessary once MilanKovacic/vite-plugin-externalize-dependencies#65 is implemented. EDIT: new version has been released. |
|
If you want to externalize all |
@vctqs1 Can you provide your vite config? I have the same problem with react but somehow your workaround won't work for me. |
in vite.config.ts with buildName is just application name (string), externals = ["react", "react-dom"] @cimchd If you still encounter issues, maybe better to share your message or something, because this is not something common so you might get something different from my issue |
|
vite-plugin-externalize-dependencies now has "full" support for externalizing modules in development: import { defineConfig } from "vite";
import externalize from "vite-plugin-externalize-dependencies";
export default defineConfig({
plugins: [
externalize({
externals: [
"react", // Externalize "react", and all of its subexports (react/*), such as react/jsx-runtime
/^external-.*/, // Externalize all modules starting with "external-"
(moduleName) => moduleName.includes("external"), // Externalize all modules containing "external",
],
}),
],
}); |
|
@MilanKovacic hi, I saw your plugin, but what we want here when externals |
|
@vctqs1 I might change the default behavior of the plugin to not automatically externalize subexports (make it configurable). For now, this can be achieved with the regex / function matching offered by the plugin. import { defineConfig } from "vite";
import externalize from "vite-plugin-externalize-dependencies";
export default defineConfig({
plugins: [
externalize({
externals: [
/^react$/, // Externalize only the "react" module
/^react-dom$/, // Externalize only the "react-dom" module
],
}),
],
}); |
Im trying your code, but there is the messsage |
|
Here is a plugin I wrote to get this working in dev and production. import type { Plugin, UserConfig } from 'vite';
/**
* Defines the document's import map and omits the specified entries from the bundle.
*
* @see {@link https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type/importmap}
* @see {@link https://github.com/vitejs/vite/issues/2483}
*/
export default (mode: string, entries: { [key: string]: string }): Plugin => ({
name: 'importMap',
config: () => {
const config: UserConfig = {
build: {
rollupOptions: {
external: Object.keys(entries),
},
},
};
if (mode === 'development') {
config.resolve = {
alias: entries,
};
}
return config;
},
transformIndexHtml: (html) => {
const content = Object.entries(entries).map(([from, to]) => `"${from}":"${to}"`).join(',');
return html.replace(/^(\s*?)<title>.*?<\/title>/m, `$&$1<script type="importmap">{"imports":{${content}}}</script>`);
},
});And, an example usage: import { defineConfig } from 'vite';
import importMap from './vite/importMap.js';
import { version as VueVersion } from 'vue';
export default defineConfig(({ mode }) => ({
plugins: [
importMap(mode, {
'vue/compiler-sfc': `https://unpkg.com/@vue/compiler-sfc@${VueVersion}/dist/compiler-sfc.esm-browser.js`,
'vue': `https://unpkg.com/vue@${VueVersion}/dist/vue.esm-${mode === 'development' ? 'browser' : 'browser.prod'}.js`,
}),
}); |
Thanks for sharing @roydukkey . The code you provided does work, however, I noticed my HMR stopped working because of the usage of then HMR continues to work. Any idea why |
|
Oh. Interesting. I found that I needed to use |
Looking at this more, the issue does not appear to be anything related to your plugin. If I create a new Vite project, and simply add |
|
If import map support ever makes it into the project officially, I hope it can be toggled off via config. We currently have several projects with a rather unorthodox development environment, and rely on Vite ignoring import maps entirely both during dev and at build time. For future-proofing's sake I've already authored a tiny internal plugin to scrub all import maps from our entry points at build time, but the dev server's a different story. |
|
Need the importmap available for non-js resources like SVG and HTML to be resolved natively by For some reasin in vitest browser runner the usual plugin with |
|
这是来自QQ邮箱的假期自动回复邮件。
您好，我最近正在休假中，无法亲自回复您的邮件。我将在假期结束后，尽快给您回复。
|
@sashafirsov Can you raise an issue on Vitest? I think Btw, current alternative is probably https://vitest.dev/config/#browser-testerscripts, which allows injecting arbitrary script on browser mode html. |
|
If you are trying to configure Vitepress with import maps you also need to define the root |
|
for |
That is a misleading statement. For production it is a vendor choice how to distribute modules and apps. Whether particular module would be taken from CDN or bundled into the app code. Rather taking sides, both options IMO should be respected: bundling via aliasing, and importmap for externalizing. But is it a focus for vite? Perhaps not, as that is an option more toward builders like Rollup. |
Is your feature request related to a problem? Please describe.
Currently it's not possible to use importmaps with Vite, because vite resolves all node_modules by default. So if I would want to use import maps with modules on cdn, rather then node_modules, I cannot.
Describe the solution you'd like
Easy on/off switch, resolve.node false
I know main advantage of Vite is transforming node_modules, but having option to also use benefits of using esm modules from cdn with importmaps is also great.
The text was updated successfully, but these errors were encountered: