Alias from an absolute path to package name on Windows about vite HOT 12 CLOSED

plugin-alias only matches ${keyname}/something and won't match ${keyname}\\something.
https://github.com/rollup/plugins/blob/8550c4b1925b246adbd3af48ed0e5f74f822c951/packages/alias/src/index.ts#L18

Even if we changed that to match \\, the replaced result would be ${keyname}\\foo.cjs. This is not a valid package specifier. It needs to be ${keyname}/foo.cjs or ${keyname}/foo or ${keyname}/dist/foo.cjs depending on the exports field.

I'm not sure if there's a way that would benefit generally.

from vite.

I see. Thanks for the explanation.

I understand the complication, however, do you think it's possible to have a unified intermediate format inside Vite for alias matching or other id handling processes?

such like if { find: "/@fs/C:/xxx" } has a chance to match all the resources below:

• /C:/xxx
• /@fs/C:/xxx
• C:\xxx
• /@fs/C:\xxx

That would be very helpful in cases Vite accepts absolute paths on different OSs.

Thanks again.

from vite.

Would you explain why you think this feature should be builtin? (as I guess it's possible by putting multiple alias entries and the usecase feels like an edge case)

Also why do you need to alias IDs containing /@fs? IIUC the ID resolution works like:

input id --(resolve 1)--> resolved id --(transform to url safe id)--> /@fs/foo --(resolve 2)--> resolved id

IDs with /@fs are already resolved by "resolve 1", so if you want to resolve it to a different path, I guess you can resolve it to a different path by "resolve 1" and not "resolve 2".

It would be helpful too if you can explain when each IDs happen as I don't know when it happens. Especially, the /C:/xxx case feels like a bug to me.

from vite.

Sure.

In short the format /C:/xxx comes from dirname(new URL(import.meta.url).pathname).

To explain the whole original program on posix-based system first, some keypoints:

• the entries (input of our program) are some custom absolute paths, like:

  /Users/zhaoj/code/reproductions/entry-foo.mjs
  

• those entry files will import some absolute paths which are inside node_modules (and in CJS, which means they needs to be optimized as deps by Vite)

  // entry-foo.mjs
  import preview from '/Users/zhaoj/code/reproductions/node_modules/@teambit/preview/preview-entry.cjs'
  

• those entry files also have some imports to a temporary package in node_modules/@teambit/_local, in this file, there are some ES imports of files from other packages and the specifiers are absolute paths

  // entry-foo.mjs
  import local from '/Users/zhaoj/code/reproductions/node_modules/@teambit/_local/local-entry.mjs'
  

  // @teambit/_local/local-entry.mjs
  import mounter from '/Users/zhaoj/code/reproductions/node_modules/.pnpm/xxx/mounter/mounter.cjs'
  

• We set some aliases to make the absolute path imports work as package imports. e.g.:

  { find: '/Users/zhaoj/code/reproductions/node_modules/@teambit/preview/', replacement: '@teambit/preview/' }
  { find: '/Users/zhaoj/code/reproductions/node_modules/@teambit/_local/', replacement: '@teambit/_local/' }
  

So far it works very well on posix-based ones like macOS.

(I can simplify it into another reproduction if necessary.)

Then when things come to Windows, we've found in Vite dev server:

1. C:\xxx didn't work as an entry, which will cause error "Not allowed to load local resource". teambit/bit#9122

   Then we just blindly tried multiple other ways mentioned above and eventually found /C:/xxx worked as expected.

2. Some CJS files in node_modules were not well-processed anymore. That's what I'd like ask originally in this issue.

3. (another newly found one, didn't reproduce nor create an issue yet) the absolute path CJS imports in @teambit/_local didn't work neither. So far I've tried only relative paths work. e.g.

   // @teambit/_local/local-entry.mjs
   // it doesn't work (so far I only tried `/C:/xxx`)
   import mounter from '/C:/Users/zhaoj/code/reproductions/node_modules/.pnpm/xxx/mounter/mounter.cjs'
   // it works
   import mounter from '../../.pnpm/xxx/mounter/mounter.cjs'
   

That's all about it. I agree with you that /@fs/xxx might just be an internal thing. Just have no idea what the best practice should be in this case.

Thanks so much.

from vite.

A reproduction would help me understand the problem.

In short the format /C:/xxx comes from dirname(new URL(import.meta.url).pathname).

This code is incorrect. It needs to be dirname(fileURLToPath(import.meta.url)). fileURLToPath has to be used here. (nodejs/node#37845)
Vite supports /C:/abspath, but that is composed from '/' + abspath.replaceAll('\\', '/') (I'm not sure if its support is intentional though).

from vite.

I see. Back to the first issue, I tried dirname(new URL(import.meta.url).pathname) just because the output of fileURLToPath didn't work if it's the entry path which led to "Not allowed to load local resource".

e.g. <script src="C:\xxx\xxx.js"></script> in the index.html of a Vite project will get this error.

I understand according to the existing docs and issues dirname(new URL(import.meta.url).pathname) is incorrect. But which way could make it as least works?

And I will prepare another reproduction for the whole program later. 🙏

from vite.

<script src="C:\xxx\xxx.js"></script> in the index.html of a Vite project will get this error.

I think this is a bug (made an issue: #17910)

from vite.

@sapphi-red here is another reproduction for the minimized program:

https://github.com/Jinjiang/reproductions/tree/vite-windows-path-20240821

You can consider debug/init.mjs + debug/run.mjs is the original program, and debug/init-win.mjs + debug/run-win.mjs as how we tried to adapt Windows so far. 🙏

from vite.

I took a look at your repro. This change worked for me.

diff --git a/debug/init.mjs b/debug/init.mjs
index 5c3c78b..bc49c26 100644
--- a/debug/init.mjs
+++ b/debug/init.mjs
@@ -1,8 +1,9 @@
 import { writeFileSync } from 'fs';
+import path from 'path';
 import { files } from './data.mjs';
 
-writeFileSync(files.index, `<script type="module" src="${files.main}"></script>`)
-writeFileSync(files.main, `import p from '${files.preview}'\nimport l from '${files.local}'\n\nconsole.log(p)\nconsole.log(l)`)
-writeFileSync(files.local, `import foo from '${files.foo}'\n\nconsole.log(foo)\n\nexport default 'local'`)
+writeFileSync(files.index, `<script type="module" src="${path.basename(files.main)}"></script>`) // workaround https://github.com/vitejs/vite/issues/17910
+writeFileSync(files.main, `import p from '${files.preview.replace(/\\/g, '/')}'\nimport l from '${files.local.replace(/\\/g, '/')}'\n\nconsole.log(p)\nconsole.log(l)`)
+writeFileSync(files.local, `import foo from '${files.foo.replace(/\\/g, '/')}'\n\nconsole.log(foo)\n\nexport default 'local'`)
 writeFileSync(files.preview, `module.exports = 'preview'`)
 writeFileSync(files.foo, `module.exports = 'foo'`)
diff --git a/debug/run.mjs b/debug/run.mjs
index c6c075e..08271a4 100644
--- a/debug/run.mjs
+++ b/debug/run.mjs
@@ -5,8 +5,8 @@ import { createServer } from 'vite'
 import { __dirname1, files } from './data.mjs';
 
 const alias = [
-  { find: dirname(files.preview), replacement: 'preview' },
-  { find: dirname(files.local), replacement: 'local' },
+  { find: dirname(files.preview).replace(/\\/g, '/'), replacement: 'preview' },
+  { find: dirname(files.local).replace(/\\/g, '/'), replacement: 'local' },
 ]
 
 // console.log(alias)

from vite.

I see. It works. Thanks.

So may I understand the point is always converting C:\xxx to C:/xxx (plus the relative path for entries as walkaround)?

from vite.

Yes. I guess you can make it work with \, but you need a bit more code to handle things described in #17897 (comment).

from vite.

Understood. Thanks so much. Case closed to me.

from vite.