Board Thread:Lua Help/@comment-4405550-20160124224015/@comment-4405550-20160129121926

Well, wikipedians are again well ahead of you. If you look at the bottom part of this page: Yes, but as you said, it requires an extension. Plus (as far as I can tell) it would require Wikia to update/merge the latest versions of the Scribunto extension.

I've had similar thoughts and even suggested it to staff at one point. I also developed modules such as  and  Luapreviewer Awesome! Now I don't have to write it all from scratch! My script would rely on the existence creation of a "pseudoFrame".

However, the module and script don't not handle the following: After using the pseudoFrame and returning WikiText, magic words and extension calls would resolve using the module page's context. If you want to preview a page that uses the module you are currently editing, you have to save the page or save a sandbox version first. Then you can preview by going to the actual page and either purge, or edit/preview using the sandbox version. If you are editing a module with reference to a data module (or any other module), you have to save it before you can preview properly.
 * Magic Words/Parser Functions/Extension Calls
 * #invoke tags/Templates that implement #invoke tags
 * Multiple Modules Being Edited

The node script could handle these issues in the following ways: All would be expanded with the desired page context. After pulling the wikitext from the desired preview page, the script would scan for any self references. Then, using the given arguments, call the module and replace ref with the output. Could easily combine multiple modules into a single document. It would require some some sophisticated renaming and conflict resolution checks, but not impossible.
 * Magic Words/Parser Functions/Extension Calls
 * #invoke tags/Templates that implement #invoke tags
 * Multiple Modules Being Edited

SetcontentfromFile was giving an error about an unknown module Your node version is probably out of date. "require.main.require" just loads the module as if being loaded by the script ORIGINALLY invoked by node (it just makes filesystem calls relative to the user).

Maybe add a bit of docs about setting up node, the version, the dependencies etc. I just don't want to spend too much time writing up docs for something that's going to change rapidly as I establish the module structure.

Some simple debugging tool that works like the console would help, e.g. SC.debug('print(buga")') Yea, I noticed it was a pain in the ass to create a new instance, even when you just want to make a simple console call. I noted on the project page that I planned on making all server requests static. Then I would make quick aliases/shims for things like "SC.debug" to simplify everything.

The node server may help, but wouldn't it make things more complicated to debug rather than simpler? One of the lovely things about node is that no, it really wouldn't make it much more complicated. Plus it would just exist as a mode for the script when you want to use local files from the browser.

If you don't want to start the server, you would just use the userscript.

I probably didn't mention this, but I was planning on having both a node.js implementation, and a browser based one (see browserify). The browser one would just loose file system access, but could query node for the files if the server is running, allowing for an expanded feature set (multiple modules, etc...).

Off Topic: Anyway, with 0 experience with node.js... You really should give it a try. With PHP (the single most poorly managed open source project ever) becoming more and more obsolete, and Apache unable to (efficiently) handle the needs of modern sites, node.js is taking over. It's surprisingly powerful and has one of the best library/module loaders of any language I've ever used.

Hell I used node to extract game data from and unknown data structure using nothing but the built in hex and Unicode functions.