To the best of my knowledge, currently dynamic imports only support static string values. My suggestion is that this is extended to include variable support.
The reasoning behind is to create an elegant means of enabling "hot" loading of additional content such as Blaze templates as part of a plugin approach within a CMS portal.
This was by design, as far as I know, if you allow variables when loading modules, someone can put any path there and it would be a security breach.
@benjamn suggested a module.dynamicGlob function in the "Release 1.5" pull request: https://github.com/meteor/meteor/pull/8327#issuecomment-298342802. With this function, you could specify which modules are allowed to be import(...)ed using a glob pattern.
@benjamn,
Thinking about your module.dynamiGlob solution for dynamic imports, which I like.
But I would still like to have support for a run time dynamic directory...
What about the public directory? Could the public directory be a place where any and all files are served up? So any reference to a module in /public could be resolved at run time instead of build time? Or does that create a security hole?
Dynamic modules could be loaded into public post build and then be retrievable by the client?
I tried referring to a file in the public directory via a variable in v1.5.2 and it failed, So any hope I have had that everything would be served up in the public directory was dashed. :-(. Maybe there is a good reason for that?
Thanks!
Would be super valuable to import using variables. It's driving me crazy adding so many import lines all hard coded to specific paths. Changing folder structure or file locations is a nightmare.
Most helpful comment
https://github.com/meteor/meteor/issues/8717