-
-
Notifications
You must be signed in to change notification settings - Fork 31
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
My library uses dynamic imports by design #104
Comments
Is the issue that it bundles dynamically loaded modules when you don't want it to? If so, we could add an option to explicitly externalize them. Or is the issue that it throws an error because it can't resolve your dynamic imports? If that's the case, we could suppress the errors and turn them into warnings instead. |
It's throw an error because it can't resolve dynamic imports, but i use dynamic imports in my library by design (autoload - imports things at runtime by glob pattern and uses it) |
Gotcha, yeah we should not be throwing errors. I might be able to find time for this in the next week or two, but I'm happy to accept a PR to address this if you'd like to work on it. |
Let's enable it by default and we can release it as a fix since this is an unexpected breakage |
Feature request
My library uses dynamic imports by design. It autoload routes from folder and import at runtime. Imports can't be staticly analyzable and its fine for us.
How we can ignore @rollup/plugin-dynamic-import-vars usage? Maybe you can introduce a flag to disable this plugin?
As a workaraound we pin
2.5.1
versionRelated kravetsone/elysia-autoload#38
Motivations
My library uses dynamic imports by design
Alternatives
pin
2.5.1
versionAdditional context
No response
Bugs are expected to be fixed by those affected by it
Compensating engineering work financially will speed up resolution
The text was updated successfully, but these errors were encountered: