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

How to get information about dynamic imports in plugin context #3232

Closed
2 of 4 tasks
btd opened this issue Nov 15, 2019 · 10 comments · Fixed by #3449
Closed
2 of 4 tasks

How to get information about dynamic imports in plugin context #3232

btd opened this issue Nov 15, 2019 · 10 comments · Fixed by #3449

Comments

@btd
Copy link
Contributor

btd commented Nov 15, 2019

Documentation Is:

  • Missing
  • Needed
  • Confusing
  • Not Sure?

Please Explain in Detail...

If i use generateBundle hook, i can get imports and dynamicImports for chunks. If i go deep starting to get dependency graph with this.getModuleInfo function - it returns only importedIds, which do not contain info about dynamic imports. It could be simplified to like:

C ---> A --- dynamic ---> B
       |
       v
       D

In this case i will get C->A, A->D only.

Your Proposal for Changes

Include dynamicImportedIds to this.getModuleInfo? Or somehow to get this info from chunk if it was generated because it was imported by some other place?

Thank you

@lukastaegert
Copy link
Member

Will add this to an upcoming PR, thanks for your patience!

@btd
Copy link
Contributor Author

btd commented Mar 20, 2020

Thanks, yesterday i tried to implement it myself

@lukastaegert
Copy link
Member

What timing... This is the PR in question: #3449

@btd
Copy link
Contributor Author

btd commented Mar 20, 2020

May i ask question while you are here. Is it possible to gather source after treeshake? I mean with removed imports/exports and if some parts of not used code removed?
I need this to make more precise gzip/brotli size (currently i just get it from transform hook)

@lukastaegert
Copy link
Member

Theoretically yes, but it would not be for free performance wise. We could add a getter to the return value that calculates the size on call.

@btd
Copy link
Contributor Author

btd commented Mar 20, 2020

Ahh, ok. I imagined something like this. Thanks anyway.

@lukastaegert
Copy link
Member

I might still add this in the way I described. It should not be hard to implement, it will be just another .toString on the magicString bundle. The question is what should happen if you call it before tree-shaking, I would probably let it throw.

@btd
Copy link
Contributor Author

btd commented Mar 20, 2020

Yes, all wrong usage should throw ideally. It is better to be explicit that something used not right instead of silent fail.

@lukastaegert
Copy link
Member

Ok, I decided to not add this yet as I would rather first refactor the hashing algorithm before making this available. I must admit this is not ideal, could you reopen a separate issue for making the rendered source available so that it is not forgotten?

@btd
Copy link
Contributor Author

btd commented Mar 23, 2020

Thanks a lot. I will create one more

lukastaegert added a commit that referenced this issue Mar 24, 2020
* Do not strip JS extensions for AMD if the user returns a replacement string in resolveDynamicImport

* Get rid of default plugin

* Support custom rendering for dynamic imports

* Add dynamic imports to getModuleInfo, resolves #3232

* Improve coverage

* Add documentation

* Deprecate `dynamicImportFunction`

* Slightly improve performance
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants