-
Notifications
You must be signed in to change notification settings - Fork 473
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[NEXT] Crashes on rc.9 and rc.10 Only file and data URLs are supported by the default ESM loader
#1518
Comments
For reference, that's the nuxt teams take on the issue: nuxt/nuxt#14877
|
Hey @kazupon, just wondering if you happen to have a rough estimate on this one? It's blocking us from upgrading our nuxt rc version so we're still stuck on rc8 which is kind of unfortunate since there have been a ton of critical fixes since then. Thank you and thanks for your awesome work! 🔥 |
I'm resolving this issue with file protocol, but, I'm a bit stuck with vite why not being able to resolve it 😞 |
Awesome, thank you - well that's good news then! I'm pretty New to vite and the whole tooling as well so unfortunate I cant comment much on that. Maybe daniel would be able to give advice in this issue though 🙏 |
How is it now? I'm stuck with the same problem, my project won't be able to access either page without adding the |
Hi ! it only happens with window for me. A workaound is to run the project on WSL (install + dev/build). I hope this can help ! |
What I don't understand here is what is the point of absolute path. I thought that was generally considered a bad practice? I have the same issue on lastest Nuxt rc.12 and @nuxtjs/i18n 8.0.0-alpha.3.
Generated file .nuxt/i18n.options.mjs contains
I've manually hacked the function
and nuxt loads just fine, with i18n working. I had to add the assert part because without it theres another issue:
So, why not use relative paths? Also the function to generate import, genImport, from dependency knitwork, doesn't know how to handle import with |
I am very unfamiliar with Windows (haven’t touched it in years), so I might say something stupid, but shouldn’t the path begin with |
This has nothing to do with Windows, RFC 1738 defines file url as |
I've just released |
The absolute path issue seems to work but I have now an new issue with the assert type
|
currently knitwork does not seem to support generating type assertions :-( |
I'll push the PR that is supported import assertions on knitwork |
I've just support import assertions for |
@kazupon Testing with just released beta.5, the // .nuxt/i18n.options.mjs
export const resolveNuxtI18nOptions = async (context) => {
const nuxtI18nOptions = Object({})
const vueI18nOptionsLoader = async (context) => import("X:/path/to/config/vue-i18n").then(r => (r.default || r)(context))
// ...
} |
I think this issue has already fixed latest version so far. Thanks! |
Version
@nuxtjs/i18n:
@nuxtjs/i18n@8.0.0-alpha.1-27710980.d1ee9d2
nuxt:
3.0.0-rc.9
Nuxt configuration
Please change to
[x]
if relevant for this issue:nuxt generate
)Reproduction Link
I tried updating from rc8 to rc9 today and got the error message below when trying to start in dev mode.
Tried deleting .nuxt, node_modules as well as package-lock.json to get a fresh install but it all resulted in the same error. Same story for rc10 and edge rc11.
https://github.com/warflash/nuxt_7426
Steps to reproduce
Clone the repo on windows and run
npm run dev
What is Expected?
The instance starts as normal
What is actually happening?
500 Only file and data URLs are supported by the default ESM loader. On Windows, absolute paths must be valid file:// URLs. Received protocol 'f:' at new NodeError (node:internal/errors:371:5) at defaultResolve (node:internal/modules/esm/resolve:1016:11) at ESMLoader.resolve (node:internal/modules/esm/loader:422:30) at ESMLoader.getModuleJob (node:internal/modules/esm/loader:222:40) at ModuleWrap. (node:internal/modules/esm/module_job:76:40) at link (node:internal/modules/esm/module_job:75:36)
The text was updated successfully, but these errors were encountered: