Dynamically import all .js files from a given subfolder of the Scripts folder?

Is it possible to dynamically import all .js files found in a specified subfolder of the C3 project Scripts folder? I think this may work in Node, but in a browser it looks trickier, and might involve C3 scripting API use. Though I'm not sure getting a C3 project folder's file/contents list is supported in the C3 API.

e.g.

Suppose, within the C3 project "Scripts" folder, I create an "entity_definitions" folder. In that subfolder, I create several individual js files, each exporting an entity definition. Can I, at runtime, get a list of the files names in that folder, and dynamically import them?

Motivation

There are a variety of preset js-objects I want to define, and I'd like to organize these definitions as one definition per .js file.

I want to collect these .js files in to packs of definitions that all reside in their own folder.

Roughly speaking, I'll end up with some folders (e.g. "pack1", "pack2", "pack3"), each containing a bunch of little .js files.

For flexibility and extensibility reasons, I would prefer not to have to hardcode the names of all these files directly into import statements in the game code. (Also kind of nice for modding.)

My understanding of the Node context so far

I think this should be possible in a Node context using the core "fs" module.

That is, if I export for node, or use remote preview for Node, I think this is doable.

My understanding of the Browser context so far

However, in a browser context, the file-system is not directly accessible, so I think I'd need to use some C3 API feature to get access to files that were part of the C3 project file hierarchy. I'm pretty sure C3 provides a way to get single files by name, but I'm not sure about getting a list of file names from a C3 project folder.

Some notes

It's not a must that the final project work directly in a web browser, but it's a nice-to-have, and it would be convenient to use the default chrome-based preview, instead of remote preview. (Though I do very much appreciate that the remote preview in Node feature exists, as it may turn out to be a critical part of my work on this project.)

Anyway, any thoughts or suggestions are welcome.

The web has no built-in file listing feature. You can only make HTTP requests to named resources. Construct knows which files are in your project, but it doesn't know if you uploaded any other resources after exporting your project, so it can't have a true "list files" features.

It should be easy to work around though: either keep your own array of filenames somewhere, or what I'd recommend is having a top-level import for the folder. For example if you have the files:

myfolder/module1.js

myfolder/module2.js

myfolder/module3.js

Then add myfolder/main.js which imports those modules. You can use "export from" syntax to conveniently re-export everything without having to list all its exports, e.g.:

export * from "./module1.js";
export * from "./module2.js";
export * from "./module3.js";

Thanks for the info and the suggestion Ashley.

I like your idea of grouping all the imports in a hub file, so the individual files get to stay individual, but in a web context they can still all be imported through that one hub file.

In my particular case, I think it's not a problem that, when running in a web context, the game won't know about additional files after export, as I'd likely only need that functionality in a Node version of the project anyway.

I expect I'll ultimately export the final incarnation using Node, and incorporate some fs reliant features, but in the meantime, just being able to do the majority of the previewing directly in Chrome with a single click is really nice and streamlined. And the hub file idea should make that work pretty nicely.

I plan to make my game logic interact with stored data through a custom data storage interface, that detects the web or Node context the project is running in, changing file access techniques and enabling or disabling related features. So the hub file was kind of the last puzzle piece to let me keep nearly everything the same for the core game data.

Thanks again Ashley, I really appreciate that you take the time to answer so much stuff in the forums.