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

Vite ignores resolve.mainFields, if ssr is false #8659

Closed
7 tasks done
sheremet-va opened this issue Jun 19, 2022 · 2 comments · Fixed by #10071
Closed
7 tasks done

Vite ignores resolve.mainFields, if ssr is false #8659

sheremet-va opened this issue Jun 19, 2022 · 2 comments · Fixed by #10071
Labels
p3-downstream-blocker Blocking the downstream ecosystem to work properly (priority)

Comments

@sheremet-va
Copy link
Member

Describe the bug

When transforming files without ssr flag Vite resolves package path to module entry point in package.json, even if resolve.mainFields is empty.

This doesn't happen, if we transform files with ssr: true. Not sure if this is a bug, or this options is intended to work differently between web and ssr.

Reproduction

https://stackblitz.com/edit/node-gslx3n?file=vite.config.ts,package.json,Comp.vue,vite-repro.mjs

System Info

Any

Used Package Manager

npm

Logs

No response

Validations

@sapphi-red
Copy link
Member

This part runs without regarding resolve.mainFields when ssr is false.

// if exports resolved to .mjs, still resolve other fields.
// This is because .mjs files can technically import .cjs files which would
// make them invalid for pure ESM environments - so if other module/browser
// fields are present, prioritize those instead.
if (targetWeb && (!entryPoint || entryPoint.endsWith('.mjs'))) {
// check browser field
// https://github.com/defunctzombie/package-browser-field-spec
const browserEntry =
typeof data.browser === 'string'
? data.browser
: isObject(data.browser) && data.browser['.']
if (browserEntry) {
// check if the package also has a "module" field.
if (
!options.isRequire &&
typeof data.module === 'string' &&
data.module !== browserEntry
) {
// if both are present, we may have a problem: some package points both
// to ESM, with "module" targeting Node.js, while some packages points
// "module" to browser ESM and "browser" to UMD.
// the heuristics here is to actually read the browser entry when
// possible and check for hints of UMD. If it is UMD, prefer "module"
// instead; Otherwise, assume it's ESM and use it.
const resolvedBrowserEntry = tryFsResolve(
path.join(dir, browserEntry),
options
)
if (resolvedBrowserEntry) {
const content = fs.readFileSync(resolvedBrowserEntry, 'utf-8')
if (
(/typeof exports\s*==/.test(content) &&
/typeof module\s*==/.test(content)) ||
/module\.exports\s*=/.test(content)
) {
// likely UMD or CJS(!!! e.g. firebase 7.x), prefer module
entryPoint = data.module
}
}
} else {
entryPoint = browserEntry
}
}
}

This seems to be the reason.

@sapphi-red sapphi-red added bug p3-downstream-blocker Blocking the downstream ecosystem to work properly (priority) and removed pending triage labels Jun 19, 2022
@sheremet-va
Copy link
Member Author

I've also noticed it still uses browser main field, even if I remove if from mainFields, when ssr is true: https://github.com/gdonoso94/vitest-prisma-integration-test

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
p3-downstream-blocker Blocking the downstream ecosystem to work properly (priority)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants