Skip to content
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

Discrepancies Between System Directories and Aliases #138

Open
shellscape opened this issue Feb 28, 2024 · 0 comments
Open

Discrepancies Between System Directories and Aliases #138

shellscape opened this issue Feb 28, 2024 · 0 comments

Comments

@shellscape
Copy link

shellscape commented Feb 28, 2024

This may affect more than MacOS, but on MacOS /private/tmp is aliased to /tmp. When started, Vite (really Rollup) will start inspecting imports and any imports from /tmp will appear as /private/tmp/... as the importer. This is important, because the way that vite-tsconfig-paths configures the projectDir uses the alias of /tmp in this scenario.

To inspect what was happening, I added some debugging around this line:

let projectDir = dirname(importer)

  vite-tsconfig-paths {
  vite-tsconfig-paths   importer: '/private/tmp/jsx-email-test/fixtures/templates/paths.tsx',
  vite-tsconfig-paths   prevProjectDir: undefined,
  vite-tsconfig-paths   projectDir: '/private/tmp/jsx-email-test/fixtures/templates',
  vite-tsconfig-paths   resolversByDir: { '/tmp/jsx-email-test/fixtures': [ [AsyncFunction (anonymous)] ] }
  vite-tsconfig-paths }

And we can see that the matching is going to fail because the directory that the plugin is looking for doesn't include /private. When we start the Vite server targeting /private/temp/app instead, everything works as expected.

This also applies if one uses the $TMPDIR environment variable, which returns a value like /var/folders/07/ywbfgwc57_z4yx4m8vzhr8580000gp/T/, which is then prefixed with /private on MacOS to appear as /private/var/folders/07/ywbfgwc57_z4yx4m8vzhr8580000gp/T/ during resolution.

This is a pretty nuanced edge case, but I wanted to share for folks that might run into a similar problem. I think the package could also do with a good bit more debug output so people can triage without having to source dive.

To resolve this case, the plugin should always wrap paths with fs.realpathSync() or equivalent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant