search

tmedwards / tweego

Tweego is a free (gratis and libre) command line compiler for Twine/Twee story formats, written in Go.
https://www.motoslave.net/tweego
BSD 2-Clause "Simplified" License
124 stars 23 forks source link

Source maps for processed js/css files? #2

Open tmedwards opened 4 years ago

tmedwards commented 4 years ago

Original request (from the old Bitbucket repo):

Would it be possible to enable output of a source map for the compiled processed javascript/CSS?

https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_to/Use_a_source_map

This would make debugging so much easier.

Original reply:

If you want Tweego to generate (and bundle) source maps:

No. Tweego neither understands nor minifies JavaScript and CSS, so it cannot generate source maps—that's well beyond its capabilities.

If you want Tweego to bundle existing source maps:

First. To use existing source maps, that you generated as part of minifying your code, you need to append a special sourceMappingURL comment to the end of each chunk of code with the URL to each source map. Frankly, that step is best done either manually or, preferably, by the tool that creates the maps.

The way that loose JavaScript and CSS files within your project are normally bundled—i.e. concatenated together into the data chunk’s script and stylesheet sections—make doing so impossible, AFAIK. Even if you had the option, it couldn’t do what you needed since the special sourceMappingURL comments get squashed into the concatenated blob. It’s also unclear if the way that story formats execute user scripts, in particular, would allow source maps to work—the mechanism also varies, complicating matters further. Ultimately, I don’t think the normal bundling mechanism will work for this.

That said, there may be a couple paths forward:

  1. Tweego currently offers the --head option, which you may use to include your JavaScript and CSS separately within the document head by encasing them within the appropriate tags—or referencing an external file. With that, you should be able to include the special sourceMappingURL comment, which points to the appropriate source map, with each code chunk. It's a little work to prepare the file you pass to the --head option, but it should give you the ability to use source maps.
  2. The next version of Tweego will optionally be able to bundle JavaScript and CSS files automatically into the the document head via a new option, which is likely to be named --module. Since each file would be bundled separately into the document head, that would allow source maps to work more or less as intended. Additionally, bundling the maps themselves might also be possible—I have no clue if providing a Data URI inline to the sourceMappingURL comment would actually work.

There’s also a potential issue with both of those possibilities for JavaScript code. The code would be executed globally, rather than as part of SugarCube’s scope, which may, or may not, be a problem.

Uzume commented 3 years ago

I like where this is going. I thought loose JS and CS files were compiled by tweego into tagged passages but apparently I am mistaken. I wonder how it decompiles such things. If they are separate in the head I can see how it might decompile such.

This also makes me question how useful it is to output strictly Twine compatible format vs. another--say where the passage data was instead encoded into JSON and the and the passage fetching functionality could be modified to use this instead of the weird Twine specific markup that the browser never directly renders anyway. Of course I understand this might affect the story formats and moving away from Twine compatibility means Twine can no longer load the output so people can no longer edit it in such. It just seems that Twine is little more than a few arbitrary rules and a graphical story/passages editor. Such things could be changed and improved upon. Maybe we need a Twine 3 type of thing. Okay--off on a tangent--sorry.