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

feat(commonjs)!: default strictRequires to true #1639

Open
wants to merge 13 commits into
base: master
Choose a base branch
from

Conversation

bluwy
Copy link
Contributor

@bluwy bluwy commented Nov 27, 2023

Rollup Plugin Name: commonjs

This PR contains:

  • bugfix
  • feature
  • refactor
  • documentation
  • other

Are tests included?

  • yes (bugfixes and features will not be merged without tests)
  • no

Breaking Changes?

  • yes (breaking changes will not be merged unless absolutely necessary)
  • no

If yes, then include "BREAKING CHANGES:" in the first commit message body, followed by a description of what is breaking. (NOTE: I've forgot to do this in my first commit)

List any relevant issue numbers: #1425

resolves #1425

additional discussion: #1618 (review)

Description

Changes the strictRequires option default from "auto" to true, based on the suggestion at #1425 (comment). This helps resolve race conditions that causes circular import detection to fail, and helps ensure the build hash is consistent.

Commit explanation:

  1. Change default
  2. Update fixtures
  3. Update some test values <---- (CI should still fail)
  4. Update remaining fails to use "auto" instead <---- (CI should pass here)

I've committed 3rd and 4th separately to view what 4th had fixed. I'd like an eye on the fails in the 3rd commit because I think it revealed some issues with defaulting to true now.

IMO the fact that true and "auto" have different exported outputs makes me a bit worried of this change. Or maybe I'm missing something.

@shellscape
Copy link
Collaborator

@bluwy checking in on this one

@bluwy
Copy link
Contributor Author

bluwy commented Jan 10, 2024

There's not much left on my end, I'm waiting for feedback on this:

I've committed 3rd and 4th separately to view what 4th had fixed. I'd like an eye on the fails in the 3rd commit because I think it revealed some issues with defaulting to true now.

@bluwy bluwy marked this pull request as ready for review January 10, 2024 05:35
@lukastaegert
Copy link
Member

I will have a look. So far, I already identified one issue with handling moduleSideEffects: In a wrapped module, it does not have any effect due to the wrapping. Instead, we need to precede every call to the require function with a pure comment if it would be false. I will see if I can make it work.
Proxies on the other hand would need to have their moduleSideEffects mirror the moduleSideEffects of the proxied module, or better with the above change, always have them set to true.

@lukastaegert lukastaegert force-pushed the commonjs-strict-requires-true branch 2 times, most recently from 2c9254b to 62bdd49 Compare January 18, 2024 05:37
@lukastaegert
Copy link
Member

Hi @bluwy. I looked at all test problems and there were indeed a few things I found. I hope I sufficiently addressed all of them:

  • Some tests just needed small updates in their assertions but were essentially fine
  • defaultIsModuleExports: false was not handled correctly for wrapped modules, which I fixed
  • I extended the readme to explain that at the moment, CommonJS entry points will only have a default export, and what to do about it
  • moduleSideEffects were not handled correctly for wrapped modules. The solution is now that whenever we have moduleSideEffects:false for a wrapped module, all transformed requires of that module will be preceded with an @__PURE__ annotation, which should have the same effect (i.e. side effects only matter if the required exports are used)

@bluwy
Copy link
Contributor Author

bluwy commented Jan 21, 2024

Thanks! I'm not too familiar with the commonjs plugin internals, so I appreciate your help taking a look 🙏 The commit messages were helpful and the changes make sense to me.

I don't have any more changes from my end, so with your changes in I think the PR should be good to go now.

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.

rollup/commonjs plugin sometimes fails to detect circular dependency
3 participants