adroitwhiz

I've been putting this off for a while because the new syntax still doesn't feel right to me, and I think I'm slowly working towards why? Fundamentally, triggers are like...

Once my big TypeScript PR is merged, I'd like to refactor trigger handling and sequencing (#163). I'll try to make sure this project works.

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...

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...

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...

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

/cc @PullJosh for your thoughts on this. Also @towerofnix, `parent` and `next` are never accessed from `BlockBase` in the `toSb3` code, right? I did a quick search through and didn't...

I think removing these would actually make it much *easier* to manipulate block stacks. It might even open up the possibility of placing the same block object in multiple stacks...

> Every importer would be forced to fix faulty projects on import, which isn't a terrible thing. Every importer would have its own unique way to "fix" ""faulty"" projects. How...

> There isn't actually a tradeoff here. We can do a great job at representing both corrupted/broken projects and highly-structured, valid projects. It looks like you're thinking of "validity" from...