-
-
Notifications
You must be signed in to change notification settings - Fork 272
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
import: false not supported in the new runtime apis #2020
Comments
Do you have a sample repo that demonstrates the issue? |
Okay, I see what's wrong here. The way we parse versions has moved into the runtime. However, it appears that some of the fallback code was replaced with just the "require.ensure" fallback and not the other two checks. Instead, it was replaced with a "share throw error" on the getter, like you said. @2heal1 , do you have any ideas on how to re-enable this? I am working on a branch to try and add "ensureExistence", "fallback", and "load" methods to the Federation Runtime/Bundler Runtime. |
Do you mean set In build plugin ,it can work , you can check it in this demo. But runtime.init may have errors , i will check it and fix . |
Okay i check again , runtime indeed not has the options which relate to I will add the option in future. Temp workaround is you can just set |
@2heal1 I tried the approach you suggested, but that doesn't seem to work. The Example: MadaraUchiha-314/rollup-plugin-module-federation#35
![]() |
Stale issue message |
not stale. |
@ScriptedAlchemy @2heal1 Is this complete by any chance ? |
#2330 ?? |
Stale issue message |
Clear and concise description of the problem
In webpack's module federation, there's a way to declare a shared dependency as
import: false
, when we do that the bundler doesn't build a fallback for that dependency and uses what ever is registered by other containers in the shared scope.To implement this same functionality using the runtime apis, we need to provide the version information of the shared dependency to the
init
function, but there's no provision to do so because ShareArgs always require eitherlib
orget
to be provided.The version information is important as there might be multiple versions of the same dependency registered in the shared scope and the requesting entity needs to be provided with the maxSatisfying version.
Suggested solution
Add an option to either explicitly specify that the fallback for the shared module is not provided by the container or make
lib
andget
both optional forcing the runtime to look elsewhere for a fallback.Alternative
No response
Additional context
No response
Validations
The text was updated successfully, but these errors were encountered: