Core Q3 Work

[Beka Westberg]

Hello everyone!

This quarter we’re trying something new, which is giving you a heads-up about what the core team will be working on. We’ve been getting some more community contributions to the code since the summit in April, so we thought this might help to keep everyone in the loop.

Note that these are very flexible objectives/directions and things may end up being dropped or added by the end of the quarter.

That being said, this quarter we’re planning on tackling tech-debt in core. This includes improving our release processes with automations, updating our build process, and (most excitingly) moving to goog.module.

I will also be working on a separate project (related to serialization) which you will hear more about next week =)

What this means for you is:

1. Blockly is getting closer to converting to TypeScript! Which will eventually mean no more typedef errors.

2. Contributions to core may need a bit of TLC. Moving to goog.module means touching all of the files so you will likely get merge conflicts. It may be better to focus on blockly-samples if you were planning on contributing this quarter.

If anyone has questions about what we’re doing or why, we’re happy to answer them below :D And any other comments are very much appreciated as well!

Best wishes,
Beka (who is interning for the summer)

[Mark Friedman]

Just wondering why Blockly is moving to goog.module rather than to ES6 modules?

-Mark

--
You received this message because you are subscribed to the Google Groups "Blockly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blockly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/blockly/1e238861-32e6-44fb-a299-d2b8fefe6c45n%40googlegroups.com.

[Beka Westberg]

I'm not sure actually! I think it's either because:

a) goog.module makes it easier to transition to typescript

b) goog.module works better with the closure compiler, which blockly still uses

But that was decided before I joined. I'll ask on monday and get back to you with a more official answer =)

--Beka

[Beka Westberg]

Hi again Mark

I asked Christopher about your question (he's the one that's going to be kind of spearheading the project) and here's what he said:

> The short answer is that it is a stepping stone in that direction.

> The longer answer is… longer, but basically: we need to do a lot of code cleanup to get there, and goog.module forces us to do most of the required work but allows us to avoid totally breaking everything.

> Despite the syntax differences, Closure modules (goog.module) are semantically very similar to ES6 modules, but are mostly backward compatible with existing code.

I hope that helps! If anyone has further questions I'll do my best to dig up the answers =)

--Beka

[Mark Friedman]

Thanks for the update, Beka!  I had read (here) that ES6 modules are supported by the Closure Compiler, so I naively imagined that the extra work (beyond goog.module support) required for Blockly to support ES6 modules would be relatively minimal.  I don't really know the specifics, so I'll trust that Christopher and the rest of you know what you're doing ;-)

-Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/blockly/941eb8d2-6a9a-4ec5-a7e6-8615676d46c3n%40googlegroups.com.