fix(template-vite): ignore browser field for isomorphic packages

[jclab-joseph]

Packages like axios have a browser field in package.json. The main process needs to resolve the node module, not the browser module.

• I have read the contribution documentation for this project.
• I agree to follow the code of conduct that this project follows, as appropriate.
• The changes are appropriately documented (if applicable).
• The changes have sufficient test coverage (if applicable).
• The testsuite passes successfully on my local machine (if applicable).

Summarize your changes:

Packages like axios have a browser field in package.json.
The main process needs to resolve the node module,
not the browser module.

[BlackHole1]

Request code review
/cc @caoxiemeihao

[caoxiemeihao]

Need comments

ref - https://github.com/electron-vite/vite-plugin-electron/blob/v0.11.2/src/config.ts#L56-L66

[BlackHole1]

@jclab-joseph CI Lint failed. You can try execute:

npx prettier --write .

[BlackHole1]

LGTM

[BlackHole1]

@caoxiemeihao Do you have anything to add?

[caoxiemeihao]

@caoxiemeihao Do you have anything to add?

Wait a moment 😅

[caoxiemeihao]

Just keep the browserField, and in the future as well :)

export default defineConfig({
  resolve: {
    // Some libs that can run in both Web and Node.js, such as `axios`, we need to tell Vite to build them in Node.js.
    browserField: false,
  },
});

[jclab-joseph]

Just keep the browserField, and in the future as well :)

export default defineConfig({
  resolve: {
    // Some libs that can run in both Web and Node.js, such as `axios`, we need to tell Vite to build them in Node.js.
    browserField: false,
  },
});

This code will break in the future if you only use browserField. It is okay?
Wouldn't it be better if it worked even into the future when only mainFields are left?

[caoxiemeihao]

This code will break in the future if you only use browserField. It is okay? Wouldn't it be better if it worked even into the future when only mainFields are left?

browserField interferes with mainFields parsing because browserField has higher priority.

• browserField in L294
• mainFields in L1041

mainFields will always exist(we don't need to set it), and it contains browserField, which is equivalent to ['browser', 'module', 'jsnext:main', 'jsnext'], so browserField will be removed because Vite doesn't just build Web.

---

It doesn't make sense that you set the mainFields value to the same value as Vite's defalut.

[jclab-joseph]

This code will break in the future if you only use browserField. It is okay? Wouldn't it be better if it worked even into the future when only mainFields are left?

browserField interferes with mainFields parsing because browserField has higher priority.

• browserField in L294
• mainFields in L1041

mainFields will always exist(we don't need to set it), and it contains browserField, which is equivalent to ['browser', 'module', 'jsnext:main', 'jsnext'], so browserField will be removed because Vite doesn't just build Web.

What I'm concerned about is when Vite completely removes browserField functionality.
In "the future", this code will no longer work without mainFields.
browserField is already deprecated and may be removed in the near future.

[caoxiemeihao]

What I'm concerned about is when Vite completely removes browserField functionality.
In "the future", this code will no longer work without mainFields.

Vite v5.0 will remove browserField, but it has nothing to do with mainFields. There is no effect on forge either :)

[jclab-joseph]

What I'm concerned about is when Vite completely removes browserField functionality.
In "the future", this code will no longer work without mainFields.

Vite v5.0 will remove browserField, but it has nothing to do with mainFields. There is no effect on forge either :)

I don't understand yet...

It is written that instead of removing browserField in the future browser will be added to mainFields.
Wouldn't that be referring to the browser field again in this case?

[caoxiemeihao]

@jclab-joseph Sorry, I misread! …（⊙＿⊙；）…
@BlackHole1 LGTM (◐ˍ◑)

[BlackHole1]

LGTM. But I don't have merge permission.

Request CR/Merge @erickzhao @VerteDinde

[erickzhao]

Thank you for the contribution! Sorry for the edit history, I tried to make the PR title clearer and more concise.