A module loading system.

[ChapelR]

Sort of a pipe-dream, admittedly, but I wanted to throw it out there. JSDelivr has free CDN hosting for GitHub repos and stuff on NPM (example of HAL’s JavaScript being served via this CDN). That got me thinking: instead of users having to copy-paste code into Twine, filling up their editor, couldn't we just use some sort of hosting and AJAX like with formats to load up modules and libraries into Twine 2?

I envision something like Twine 1’s StoryIncludes system, where users enter a URL/path to a JavaScript or CSS file, and those files’ content is prepended, in order, to the JavaScript (or Stylesheet) of the story’s data chunk on build/play/test (i.e. not included via a load over the network but actually compiled into the project like the ordinary story JavaScript/Stylesheet).

All it really needs to be is another editor window, similar to the current story JavaScript and story Stylesheet editors, but it would probably need to be smart enough to ignore malformed content (anything that isn't a newline-separated list of URLs, for example).

I recognize that there are some complications here, like security, failure to load, etc, and that it would probably be better with actual format-end support, but I think it would be a cool feature to encourage addons, plugins, and extensions.

Edit. Fixed links.

[klembot]

This is something that furkle has been working on... see https://github.com/furkle/twinepm-server-heroku. I don't know the current state of the project, though.

[greyelf]

As such modules may also be stored locally on the Author's machine I wouldn't assume that only remote URL's will be used to reference them. I believe the main point is the ability to 'embed' the contents of a external JS / CSS file within the HTML document (or file) being generated.

Such a feature may also require the ability to influence where in the generate HTML document said content is embedded, this will need support from the story format developers.

For instance in a SugarCube project should the module be placed:

1. between the Engine JavaScript and that of Story JavaScript area, thus allowing the module to be configured in a way similar to the engine itself.

Config.history.maxStates = 0;
ModuleName.someProperty = "some value";

2. between the Story JavaScript area and the StoryInit special passage,

[ChapelR]

That furkle project is somewhat similar to what I'm suggesting, and probably potentially a little better in some ways, except for the relative complexity of implementing it and using it.

Format-side support so we can have config properties would also be great, but for just a starting point, I don't think it'd be absolutely required. I'm thinking the files would be loaded at compile time and just prepended to story JS for now (note, but only at compile time, to keep the editor clean-ish), though if story format support comes later that can change. Getting all the format authors to implement this would probably not be easy, though.

I suggested prepending the file content into story JS for two reasons: first, there will be no need for format-side support since the formats already know how to handle the JS content. Second, the author can control the load order of the files relative to each other as long as the implementation doesn't change the order, and they can be assured that all their "modules" will be loaded prior to their story JS content so that whatever JavaScript-facing APIs they import will be available to their scripts.

For now, I'm thinking that if the script has configs to set, they'll have to import the script the old-fashioned (read: current) way to edit those.

A format-only implementation would probably make this system hard for most authors to work with (requiring a connection, potential cors issues, etc), so I feel like this would always need some kind of compiler-side support to work.

It is one of those things that's easily a convenience feature, though, and I understand that there are bigger fish to fry. Just something I would love to see someday if possible.

Edit: I was using JS as an example throughout, but I also think this system could be used to add CSS and probably even passages if desired.