nollup: Missing shared dependencies across dynamic imports
Bear with me…
If I have 2 dynamic imports in my entry points, and both of them import another module, that itself imports another module… And if only the 2nd dynamic import is actually executed, then the transitive dep module is missing, which results in the following error:
Uncaught (in promise) TypeError: modules[number] is not a function
I’ve pushed a reproduction case on the bug-shared-dynamic-imports branch of my playground repo of the moment.
To illustrate, here what a simple main.js would look like:
if (false) import('./dyn1.js')
import('./dyn2.js')
Where dyn1.js and dyn2.js would both have this code:
import dep from './dep.js'
console.log(dep)
And dep.js itself would be:
import sub from './sub.js'
export default sub
It’s this sub.js module that would be missing from the dyn2.js “chunk”. It would be present in dyn1.js, but since it is skipped at runtime… Still missing.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 1
- Comments: 30 (30 by maintainers)
Just a small update on this, currently in the process of refactoring the entire code. Will be a bit of time still before it’s ready but just saying that this is being addressed. 🙂
It was more about the order in which they are run than not running some of them. But yeah, I agree, let’s make it consistent first. And maybe also confirm that it really has a damaging effect in real world.
Just tested the new version in the test case. Seems to fix everything 🎉 No more stale log either apparently.
I’m merging this into my patched branch and resume using it in my project to see how it fares in real world. I’m precisely working on adding and moving lots of files around just like in the test case.
Updated branch again. In a nutshell, dynamic dependencies were not being tracked as dependencies at all, so HMR didn’t detect them properly and bubble those dependency changes to the files that imported them. The bug repro code works for me now.
I don’t think I can do anything about accept handlers running for each module in the changes array. It’s easy in the case of a single accept handler, but when you start looking at multiple accept handlers (both in one branch or multiple branches), it gets incredibly messy. I think the objective at the moment should be ensuring that after all accept handlers have resolved, that the state is consistent with a full reload.
I have managed to make it work with a pretty complex project I’m currently working on. So far so good regarding the dynamic imports.
Now I need to do some work on the actual app, to see if I don’t have some edge cases, but what I’ve seen so far is encouraging. Apparently the the freeze / race I was encountering with my patched montage version might be gone.
In the process of hooking into my app, I had to play with the public dir things. I’m having second thoughts about it… About the discarding some files part at least. I’ll add more details about my findings in #84.
That’s great news! Thanks for the update.
I managed to patch together a somewhat working version for one of my use case, and it is very promising. I can’t wait for the well crafted version!
I’ve got 3 Svelte projects awaiting Nollup-ization – including Sapper, the official Svelte app framework, and Routify, the rising star 😄 Well, I absolutely don’t mean to pressure you, just sharing my enthusiasm… I can wait actually, I have plenty of other things to do 😅
But ready to try / review anything if you need!