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

direct deep imports prefers .js over .mjs files #127

Closed
sventschui opened this issue May 11, 2020 · 1 comment
Closed

direct deep imports prefers .js over .mjs files #127

sventschui opened this issue May 11, 2020 · 1 comment

Comments

@sventschui
Copy link
Contributor

Describe the bug

serverPluginModuleResolve currently prefers .js files over .mjs files when using direct deep imports.

A quick&dirty fix would be to replace the .js with an .mjs extension and serve that file if it exists. Not sure what a proper solution would be.

Reproduction

Add the following import to a basic vite setup:

import { Kinds } from 'graphql/language/kinds';

(See https://github.com/sventschui/vite-mjs-repro)

System Info

  • required vite version: `=> 0.14.2
  • required Operating System: OS X
  • required Node version: 13.12.0

Logs (Optional if provided reproduction)

Browser console:

Uncaught SyntaxError: The requested module '/@modules/graphql/language/kinds' does not provide an export named 'Kinds'
@sventschui sventschui added the bug label May 11, 2020
@marvinhagemeister
Copy link
Contributor

marvinhagemeister commented May 11, 2020

Dug a bit into this and the origin is in resolve-from. Internally it calls a private node resolution method:

Module._resolveFilename(moduleId, {
  id: fromFile,
  filename: fromFile,
  paths: Module._nodeModulePaths(fromDirectory)
});

Trouble is that node has no knowledge of the module field in package.json. It's something exclusively used by bundlers.

@github-actions github-actions bot locked and limited conversation to collaborators Jul 16, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants