Hi! What I want to do. I want to use dynamic module import with stimulus-flatpickr or even with every stimulus controller.
Why? Because calendar used only on one page and I do not want to weigh down assets size.
I found some github issue without any concrete technique but it was in 2019 may be something changed?
I also realize that i could make my own controller with dynamic loading of flatpickr (without stimulus-flatpickr) like described here
Is switching to webpack a possibility for you? You could always set up a pack that is just stimulus-flatpickr.
That all said… how much data are we talking about? It gets loaded once, then cached, right?
I understand some people love to bikeshed this stuff, so feel free to ignore me, but after gzip the whole dependency is likely smaller than most JPGs. How much is your time worth? Is eliminating a few KBs that you plan to download eventually really the most critical feature facing your project right now?
as part of the V2 roadmap for Stimulus-flatpick I would like to have a mixin option something like useFlatpickr in the same manner that Stimulus-use is built.
This would make it easier to make dynamic import.
In the mean time stimulus-controller-resolver looks like a great way to go. I tested and it worked well but I never used it in production.
Also the suggestion of @leastbad is another approach with a second pack that you only load on your particular page
Hmm, I’m already using it 
It’s true. But I’m aware that common modules imported in different packs (without webpack mechanism - chunks) will import modules twice (not sure on 100%). That’s increase overall assets size. For example lodash etc…
I’m planning to use charts, trix. They are too highweight for pages where they are do not required.
Just want to use technique which will not require to rewrite full frontend part
Cool. By the way I’ve already tried technique with extending controller and it seems to me, it works. Will try to dig deeper by reading stimulus-controller-resolver code luckily it’s not big. Looks very promising technique by converting any stimulus controller to async version.
Interesting. Didn’t hear about it. Will read later. Thank you.
Again, if you need to split these features out, just create packs for the heavy assets. You can include the packs only on the pages that utilize them.
I remain skeptical that anyone except you will ever notice, but hey, maybe you know something I don’t. Happens all of the time. 
Here is more detailed explanation what i meant (sorry English is my second language).
For example there are 2 packs:
application.js which includes lodash module and many other
certain_page.js which includes lodash module and many other
Then lodash will be included in both packs as separate modules.
webpack chunks mechanizm will distinguish that it is one module (with async import)
I am definitely not advising you to create a pack for every page. I was just offering you a solution to this theoretical problem. flatpickr doesn’t require lodash.
For the record, if you do use lodash, just import individual functions from lodash-es and let tree-shaking do the hard work.
For those who also interested in this question, take a look at https://webpack.js.org/guides/code-splitting/ where described all the three techniques.
entry configuration.SplitChunksPlugin to dedupe and split chunks.Here is a very interesting article from Ross about packs and potential mistakes with multiple packs