Why is code to work with scratch-js part of sb-edit?

[towerofnix]

I was trying to use webpack to build a project that depends on sb-edit, but it failed to build due to the dependency prettier trying to use the fs module. It's src/io/scratch-js/toScratchJS.ts that uses prettier, and since my project doesn't use scratch-js, I worked around the problem by just commenting out references to it elsewhere in the library code. It's probably worth investigating why scratch-js can't be built with webpack in the first place, but it got me wondering: what's the purpose of including code related to scratch-js in the otherwise more general library sb-edit? If it's not needed here, should it be moved to the scratch-js library (thus getting rid of the prettier dep for sb-edit)? I'd guess it's to make the two libraries interact better and may be difficult to separate from sb-edit, but I wouldn't really know, so just asking. :P

[PullJosh]

The scratch-js code in this repository generates strings of javascript code that are equivalent to the original project. It's called scratch-js because the generated code (the string output of this program) depends heavily on the scratch-js library. sb-edit and scratch-js never interact with each other directly, however. It is only the javascript that is generated by sb-edit that cares about scratch-js.

I think it's possible to set up the sb-edit library in a way that allows importing individual loaders/exporters (so you could import the stuff for dealing with sb2/sb3/scratchblocks/whatever without importing other stuff like the scratch-js handler), although I don't know what the right architecture is to make that happen.

[PullJosh]

Maybe in io/ the scratch-js directory should be renamed to javascript. That's really what it is. The fact that the outputted javascript happens to utilize scratch-js is just an implementation detail. Then we could add more outputs (maybe one called python that uses pygame?) over time.

[adroitwhiz]

Since the generated code is heavily dependent on the implementation of scratch-js, which is still under heavy development, why not move the export functionality to scratch-js so that it can change as scratch-js does?

My opinion is that since sb-edit is an API for reading Scratch projects into an easily workable format that many different Scratch implementations could use, placing any specific implementation's export code (other than the two "official" implementations, aka .sb2 and .sb3) into sb-edit seems to be unnecessary coupling.

[PullJosh]

My opinion is that since sb-edit is an API for reading Scratch projects into an easily workable format that many different Scratch implementations could use, placing any specific implementation's export code (other than the two "official" implementations, aka .sb2 and .sb3) into sb-edit seems to be unnecessary coupling.

@adroitwhiz I think this is right. It probably makes sense for nonstandard I/O formats to be treated like extensions or plugins of some kind. (Although at that point why not just treat all I/O formats like extensions?)

[adroitwhiz]

I think you could in fact move all the output (and maybe input) formats into a separate repo.

sb-edit would encompass:

• A way to parse existing Scratch file formats (if you don't move the parser code into another project)
• An "intermediate representation" that the files are parsed into
• A JS API for working with that intermediate representation

The "export" (and maybe "import") code would simply interface with that API.

IMO there's value in having a standardized way for JS to interact with Scratch projects that's free of implementation-specific warts (e.g. shadow blocks vs non-shadowed inputs).

For example, my Phosphorus fork Bismuth parses both SB2 and SB3 files into its own intermediate representation that it can generate JS from. I have some interest in replacing this with sb-edit's parsing code, and making the code generator use sb-edit's representation internally, once sb-edit's API has stabilized.

[PullJosh]

That all makes a lot of sense. I think the internal representation used by sb-edit needs a pretty solid upheaval. In particular, references to other objects in a project should be actual references to instances instead of string ids. (So if you have a switch to costume block, the intermediate representation in sb-edit should reference the actual costume instance in the input rather than just the string for the costume name.) This would make sb-edit much more resilient to the quirks of different engines and outputs.

To that end, I would love to see someone (@adroitwhiz? 😉) make a PR that heavily restructures the guts of sb-edit. I definitely don't feel attached my design decisions mistakes.

[adroitwhiz]

Ehh, I'd say it makes sense to have the intermediate representation of a costume be a BlockInput.Costume rather than a reference to an actual Costume. What if, for instance, there was a "switch costume to" block whose menu referenced a non-existent costume (you can make this easily in Scratch by deleting a costume)?

[adroitwhiz]

But more to the point, I'd love to look more at the internals of sb-edit once I have some time!

[towerofnix]

Ehh, I'd say it makes sense to have the intermediate representation of a costume be a BlockInput.Costume rather than a reference to an actual Costume. What if, for instance, there was a "switch costume to" block whose menu referenced a non-existent costume (you can make this easily in Scratch by deleting a costume)?

Also on that note, if you pass a reporter into the dropdown, then there are two potential, totally unrelated types for the input value - Costume or BlockInput.Block! I believe as it currently is the value can only be BlockInput.Costume or BlockInput.Block, which are two fairly similar types that are easy to differentiate - specifically by checking (a BlockInput).type.

PS: I've been following this discussion since it's interesting to me, but not really adding much, as I don't have a whole lot of thoughts either-way :P But I'm definitely excited to see what breaking apart the IO code from the main library could look like!!

[towerofnix]

I'm going to close this in favor of more comprehensive and recent discussion in #53, which covers the same topics and more.