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: enforce generating module param when needed in relative url resolving (fixes #9807) #9808

Closed
wants to merge 2 commits into from

Conversation

Tal500
Copy link
Contributor

@Tal500 Tal500 commented Aug 23, 2022

More details on the issue it fixes #9807 .

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.

@Tal500 Tal500 changed the title fix: enforce generating module params when needed in relative url resolving (fixes #9807) fix: enforce generating module param when needed in relative url resolving (fixes #9807) Aug 24, 2022
@sapphi-red
Copy link
Member

Thank you for the PR!

We are doing a similar thing in packages/vite/src/node/plugins/completeSystemWrap.ts.
I missed this case when checking (#9507 (comment)).

Maybe just updating this regex will fix your issue?

const SystemJSWrapRE = /System.register\(.*\((exports)\)/g

@sapphi-red sapphi-red added plugin: legacy p4-important Violate documented behavior or significantly improves performance (priority) labels Aug 24, 2022
@Tal500
Copy link
Contributor Author

Tal500 commented Aug 24, 2022

Thank you for the PR!

We are doing a similar thing in packages/vite/src/node/plugins/completeSystemWrap.ts. I missed this case when checking (#9507 (comment)).

Maybe just updating this regex will fix your issue?

const SystemJSWrapRE = /System.register\(.*\((exports)\)/g

Hi!

What are you suggesting to do then? I'm not an expert in vite plugins, but this is what I understand:
The regex you mentioned is fine, it catches my use case (thought unsafe in my opinion, since the expresion (export) might appear later, not in the function deceleration), but is done at an early stage (in pre): (in

return {
pre: [
completeSystemWrapPlugin(),
)

I also think it's a tiny waste to force declaring a parameter that might not be used at all.

The problem I'm facing is this: In some vite internal plugins, this can happen in this order:

  1. Rollup compiles the asset in system format.
  2. Then, in stage renderChunk, the plugins get the raw compiled Rollup code, and can process it more.
  3. They sometimes might inject new code, that sometimes depends on the definition of module.
  4. If the raw code from 1 didn't use the module definition, Rollup chooses smartly not to declare this parameter. This can conflict the behavior of Vite plugins that can inject new code in 3 that uses the definition of module.

So I think the plugin of completeSystemWrapPlugin is executed before other plugins implementing renderChunk.

The approach I have in this PR is:

  1. Whenever creating a new code that might need the definition of module, you need to return not only the new code, but also an indicator telling whether it uses the module definition (I called this indicator needModuleParam).
  2. The plugin using it in renderChunk, will just use my newly created function ensureHavingSystemJSModuleParam for forcing the signature to be function (export, module) { /* ... */ }, and only if the definition of module is really needed.

@Tal500
Copy link
Contributor Author

Tal500 commented Aug 24, 2022

Thank you for the PR!

We are doing a similar thing in packages/vite/src/node/plugins/completeSystemWrap.ts. I missed this case when checking (#9507 (comment)).

Maybe just updating this regex will fix your issue?

const SystemJSWrapRE = /System.register\(.*\((exports)\)/g

I post PR that solves my problem in your way, although I'm not sure it's good to do this way, but I do understand the safety concerns in this giant project.
See PR #9821

If the other PR is accepted, this PR can be closed.

@poyoho
Copy link
Member

poyoho commented Aug 24, 2022

Thanks for PR. This PR can fix tiny waste to force declaring a parameter.

toOutputFilePathInString generate code maybe need module params. And toOutputFilePathInString always call in renderChunk. So we can save the needModuleParam state in chunk and replace it in

const SystemJSWrapRE = /System.register\(.*\((exports)\)/g

I feel that can reduce many parameters that need to be added for state transfer

Another chose

I think we can do this in completeSystemWrap.

Pre renderChunk plugin collect what chunk needModuleParam

Post renderChunk plugin replace it by needModuleParam

@sapphi-red
Copy link
Member

Yes, this PR's approach can reduce the parameter.

But

  • it requires much more code
  • it only reduces about two to five bytes for each chunk when minified (, and the argument name)

. So I thought it does not justify the complexity.

@patak-dev
Copy link
Member

Agreed that the increased complexity doesn't justify this approach, let's go with #9821
@Tal500, I just created a v3.0 branch from the last release point (we are now preparing 3.1, beta to be out soon), would you like to cherry-pick the commit to backport this fix to the new branch? https://github.com/vitejs/vite/tree/v3.0

@patak-dev patak-dev closed this Aug 25, 2022
@Tal500
Copy link
Contributor Author

Tal500 commented Aug 25, 2022

Agreed that the increased complexity doesn't justify this approach, let's go with #9821 @Tal500, I just created a v3.0 branch from the last release point (we are now preparing 3.1, beta to be out soon), would you like to cherry-pick the commit to backport this fix to the new branch? https://github.com/vitejs/vite/tree/v3.0

Tnx! But I didn't understand the question...

@patak-dev
Copy link
Member

@Tal500 don't worry, I'll do it before we release 3.0.10. I was talking about cherry-picking this commit (1ee0364) into the v3 branch. main is currently for the next minor (3.1), and this is an important enough fix to justify a new patch in 3.0

@Tal500 Tal500 deleted the css-module-fix branch December 11, 2022 11:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
p4-important Violate documented behavior or significantly improves performance (priority)
Projects
None yet
4 participants