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

Enhancement - opt-out of warnings on dynamic import modules with a static import #13848

Closed
4 tasks done
andygup opened this issue Jul 14, 2023 · 7 comments · Fixed by #13884
Closed
4 tasks done

Enhancement - opt-out of warnings on dynamic import modules with a static import #13848

andygup opened this issue Jul 14, 2023 · 7 comments · Fixed by #13884
Labels
contribution welcome enhancement New feature or request p2-nice-to-have Not breaking anything but nice to have (priority)

Comments

@andygup
Copy link

andygup commented Jul 14, 2023

Description

After upgrading to 4.4, local builds with our library now generate many dynamic import will not move module into another chunk warnings. These warnings are helpful for simple cases with a single static import that is also dynamically loaded. However, for more complex cases this also generates many warnings for external dependencies that aren't actionable.

Related PR: #12850

Reproduction

https://stackblitz.com/edit/vitejs-arcgis-ts-mxc2t2?file=package.json,main.js

Steps to reproduce

  1. Ctrl C to stop the default Stackblitz process
  2. npm run build
  3. Observe plugin:vite:reporter build output to console

Suggested solution

Have plugin:vite:reporterdefault to not warn for external dependencies since it's not really actionable by the developer, and instead only warn for the app's own modules.

Also, consider making the warning optional. For example, this would allow end-users of a library to mute the warnings while a fix is in-progress.

Alternative

No response

Additional context

No response

Validations

@stackblitz
Copy link

stackblitz bot commented Jul 14, 2023

Fix this issue in StackBlitz Codeflow Start a new pull request in StackBlitz Codeflow.

@sapphi-red sapphi-red added enhancement New feature or request contribution welcome p2-nice-to-have Not breaking anything but nice to have (priority) labels Jul 16, 2023
@sapphi-red
Copy link
Member

Also, consider making the warning optional. For example, this would allow end-users of a library to mute the warnings while a fix is in-progress.

You can filter out the warning with build.rollupOptions.onwarn
https://rollupjs.org/configuration-options/#onwarn

@bluwy
Copy link
Member

bluwy commented Jul 17, 2023

I suppose it make sense to opt-out automatically if it's coming from node_modules. But I'm not sure how to re-opt-in for those cases again, but maybe it's not a huge deal.

@chaejunlee
Copy link
Contributor

Hello, I would like to work on this issue. However, I am not so sure how much I should do.

module.dynamicImporters.some((m) => chunk.moduleIds.includes(m))

I am assuming that from @bluwy's comment, if the m of module.dynamicImporters.some((m) => chunk.moduleIds.includes(m)) has a string "/node_module/", just skip the warning. This is because if m has "/node_modules/", then the .some(...)'s "true returning" chunk.moduleIds would also include "/node_modules/". Is it what this issue is trying to solve?

@andygup
Copy link
Author

andygup commented Jul 17, 2023

Is it what this issue is trying to solve?

@chaejunlee correct, the goal is to skip warnings for modules that exist in node_modules. And, allow for re-opt-in as @bluwy pointed out.

@chaejunlee
Copy link
Contributor

@andygup would you mind checking my PR? What do you think about it?

@andygup
Copy link
Author

andygup commented Jul 20, 2023

Huge thanks to all and @chaejunlee for the assistance on this issue!

I verified this issue using 4.4.5 and the build looks clean. 🎉

@github-actions github-actions bot locked and limited conversation to collaborators Aug 4, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
contribution welcome enhancement New feature or request p2-nice-to-have Not breaking anything but nice to have (priority)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants