Thanks so much for putting together this series of plugins! They solve the exact problem I have, but, I have it within my own monorepo, both across local packages and for relative dynamic imports within them. Reading over the source it seems like a fixed list of top-level module names are required in the packages config. Any relative import gets back undefined from getPackageName, which means it can't ever be included in the list of packages in the config.
How hard would it be to:
add a mode where every dynamic import is always processed
or maybe add a mode where every relative dynamic import is always processed?
If you could give me a little guidance on the best path forward and how to do it I can put together a PR!
My assumption is that default exports get problematic only at package boundaries, because:
Most packages can be configured to simply use the same module type across the package, and in this case, you don't see the default export problem.
If not for the first bullet: Within a single package, the author has the freedom to change both the importing module and the exporting module to avoid default exports. Even if the module in question is imported both from within the package and outside the package, you can just create an intermediate module to segregate them.
So, could you explain your use case here so that I can reconsider the assumption?
Thanks so much for putting together this series of plugins! They solve the exact problem I have, but, I have it within my own monorepo, both across local packages and for relative dynamic imports within them. Reading over the source it seems like a fixed list of top-level module names are required in the
packages
config. Any relative import gets backundefined
fromgetPackageName
, which means it can't ever be included in the list of packages in the config.How hard would it be to:
If you could give me a little guidance on the best path forward and how to do it I can put together a PR!