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

fix(ssr): change CommonJS and resolve plugin order #10450

Closed
wants to merge 1 commit into from

Conversation

jiby-aurum
Copy link
Contributor

@jiby-aurum jiby-aurum commented Oct 12, 2022

Description

When trying to build a node library with the ssr mode, vite was failing with couple of issues

  1. CommonJS modules were not always transformed. The specific case for me was dependencies that are CJS build of ES module codebase with __esModule flag set, in this case vite ended up assuming that files in the dependency imported by files in the dependency itself are ES modules instead of CJS. Applying the CommonJS plugin earlier fixed this issue

  2. Tree shaking was just not working, I got ~34MB builds and the build did not reference imports properly and was broken. Apply the resolve plugin later fixed this issue, the build came down to ~5MB and generated build was correct.

I figured this out by testing bundling by just using rollup and rollup plugins, there also I was able to reproduce the issue when the CommonJS plugin is not applied early and resolve (the rollup one, not vite one, though I guess similar) is not applied later.

Just as a side note, I did try, enabling the dep optimiser and disabling CommonJS, which did solve the two issues above, but I had the issue that default exports from node builtins were not working. I have a minimal repro of that in this repo https://github.com/jiby-aurum/vite-issue. You will be able to repo it by cloning and running npm i && npx vite build && node dist/index.mjs. However I did not report an issue with it, as its experimental and not supported at the moment anyways.

Additional context

I am very new to the vite codebase and I am not sure if the order change of plugins is going to break something else. If it won't I would really appreciate if we can land this in 3.2 which is the next release in the pipeline


What is the purpose of this pull request?

  • Bug fix
  • New Feature
  • Documentation update
  • Other

Before submitting the PR, please make sure you do the following

  • Read the Contributing Guidelines.
  • Read the Pull Request Guidelines and follow the Commit Convention.
  • Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
  • Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
  • Ideally, include relevant tests that fail without this PR but pass with it.

@jiby-aurum jiby-aurum changed the title Change CommonJS and resolve plugin order to fix broken ssr build fix: change CommonJS and resolve plugin order to fix broken ssr build Oct 12, 2022
@jiby-aurum jiby-aurum changed the title fix: change CommonJS and resolve plugin order to fix broken ssr build fix(ssr): change CommonJS and resolve plugin order Oct 12, 2022
@jiby-aurum
Copy link
Contributor Author

greatly appreciated if one of you can take a look at it @bluwy @patak-dev

@bluwy
Copy link
Member

bluwy commented Oct 13, 2022

Changing the order of plugins would almost always break things, and the tests are currently failing. I haven't looked deep into the issue, but I think it needs a different solution.

@jiby-aurum
Copy link
Contributor Author

jiby-aurum commented Oct 13, 2022

@bluwy I did not really look into tests, because locally some were already failing for me in main branch strangely.

Also not sure if it makes any sense to try to fix the CommonJS plugin, as we are anyways plan to move to dep optimiser. The issue I had with the dep optimiser was a much more straightforward one, it seemingly does not handle default exports properly. Basically with const EventEmitter = require("events"), EventEmitter should be a constructor function with the exports on it, however going through dep optimiser it becomes just a object with the exports on it. If you have any pointers what may be the cause, I can try to debug/fix rather the dep optimiser

@jiby-aurum
Copy link
Contributor Author

@bluwy I close in favour of #10406, I commented a small change there, that just fixes the dep optimisation for me.

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

Successfully merging this pull request may close these issues.

None yet

2 participants