debugging Twine story -- need to remove minification at publish

Question

I'd like to be able to disable the minification of Javascript that occurs when the author chooses 'publish story' from the Twine app UI.  As far as I can tell this is hardcoded into the app by default, so I assume I'll need to rebuild it from source.  My development platform is Windows and Linux, so I think the repo I want is https://github.com/tweecode/twine, but I'm not certain.  I'd like to grok the whole codebase, but since I really only want to tweak that one feature can anyone point me towards where the minification occurs?

Answer 1

The JavaScript contained within a Twine generated story HTML file falls into one of two categories:

1. That which was added by the Author to their project's Story Javascript area.

This JavaScript is embedded into the #store-area element of the selected Story Format's template as is, there is NO minification process being applied to this code by the Twine application. The same is true for any CSS placed within the Story Stylesheet area.

eg. If the code within the Story Javascript area is formated, has blank lines, and includes comments then the copy of it within the #store-area element will also have them.

2. That which makes up the story format's built-in JavaScript based engine.

Each Story Format Developer is responsible for suppling it's template, they also control if the CSS and JavaScript that comes with the template has been minimised or not. The Developers often include copies of third-party JavaScript libraries (like jQuery) in the template, these are often pre-minimised.

If you want a unminimised version of a particular Story Format then you may have to build your own custom copy of it. Each Story Format has it's own repository.

note: The tweecode/twine repository you linked to is actually the one for the discontinued Python based Twine 1.x application. The HTML5/Electon based Twine 2.x application's repository can be found here.

Answer 2

You can import Twine 2 stories into Twine 2 and edit the code there.  If it's a Twine 1 story you can either import that into Twine 1 or there's a Twine 1 to Twine 2 converter in the utilities section here that you can use and then import it into Twine 2.

If any of the JavaScript in a Twine game is minified, then it was minified before Twine compiled it.  After you import the HTML into Twine, you can then go into the JavaScript section, copy the code from there, drop that code into a beautifier (like this one), then edit the beautified JavaScript, copy it back into Twine, and then publish it with your tweaks.

Hope that helps!  :-)

Comments

cool, cool but the stack trace I'm staring down in the browser comes from a Passage and says:

Uncaught Error: <<run>>: bad evaluation: puckChar is not defined
    at Function.value (Fuzziolump.html:4888)
    at HTMLAnchorElement.<anonymous> (Fuzziolump.html:4889)
    at Fuzziolump.html:4889
    at HTMLAnchorElement.<anonymous> (Fuzziolump.html:4889)
    at HTMLAnchorElement.<anonymous> (Fuzziolump.html:4886)
    at HTMLAnchorElement.<anonymous> (Fuzziolump.html:4886)
    at HTMLAnchorElement.dispatch (Fuzziolump.html:60)
    at HTMLAnchorElement.q.handle (Fuzziolump.html:60)

and line 4888 is a minified single string about 32,000 columns long that definitely isn't my code.  I think I need to hit up the Sugarcube story format per Greyelf's answer.  Thanks!

---

If you're attempting to localize the problem shown in your trace, then that's not going to tell you much more than the error already does.

Based on the error, you've likely defined puckChar with Story JavaScript (Twine 2) or a script-tagged passage (all other compilers). All script evaluations run silo'd within their own scope, so local definitions do not carry between them.

It would probably be easier if you simply defined puckChar where it can be accessed by, I'm assuming, your code running within passages.  Namely, either attached to window, making it an auto-global, or the setup object.

---

As TheMadExile said, the place where the stack trace is pointing to is merely the place where your code triggered the error, however, that's not actually where the error in your code actually is.

Think of it like if you ordered a package online, but gave them the wrong delivery address.  They'll take your order, but the error won't be noticed until they try to deliver it.  So the error may be discovered by the delivery truck driver, but the error wasn't caused by the delivery truck driver.  The error happened further up the chain.  The same thing is happening here.

The source of the problem will almost certainly originate in the game author's code, not in the underlying Twine/SugarCube code which that stack trace is pointing to.

Basically, it looks like a <<run>> macro is used somewhere which is trying to use "puckChar", where "puckChar" isn't defined.  You need to figure out where that particular <<run>> macro is and then debug it there, not where the stack trace is pointing you to.

Hope that helps!  :-)