Is your feature request related to a problem? Please describe.

A combo box field.

Describe the solution you'd like

A field that has both a text / number input, and a dropdown of options allowing developers to choose a set of options to display to users.

Additional context

Something like this:

Think about

• What will the API look like?
• Can we extend core blockly fields to achieve this.
• What will accessibility look like. https://www.w3.org/TR/wai-aria-practices/examples/combobox/aria1.1pattern/listbox-combo.html
• On a related note, how do we handle focus between the two?

Currently context menus for variables look like this:

It would be better if they looked like this:

Ideally the block could be dragged out (like from a flyout), but also consider it just being a graphical button which creates the block when clicked (like the existing menu row). This would apply to the context menus of variable blocks, for/in loops, function arguments, and maybe some others.

This issue should not be addressed right now, since the context menus are due for rewriting. They were copied from Closure and suffer from code bloat. However, while rewriting these menus, we should keep this issue in mind.

How to achieve this goal is an open question. Maybe the menu row should be a flyout. Maybe the menu row should contain a dynamically-generated PNG with XML payload. Maybe the menu row should be a workspace.

This proposal is a result of seeing @BeksOmega unexpectedly drag a block out of a field, followed by the rest of us dragging our jaws off the floor.

Thank you for the react blockly example!
But npm install reports several deprecated libraries are being included:

npm WARN deprecated [email protected]: Please update: there are crash fixes
npm WARN deprecated [email protected]: I wrote this module a very long time ago; you should use something else.
npm WARN deprecated [email protected]: use String.prototype.padStart()

Also a warning that may or may not be important:

node-pre-gyp WARN Using request for node-pre-gyp https download 

Can these warnings be fixed? Thank you,
Larry

ps. Unfortunately I'm still quite new to ReactJS or I'd try to fix them myself.

Problem statement

I like the behaviour of Blockly.Events.disableOrphans, but it only makes sense in conjunction with the workspace disable option - to suppress the 'disable' item from the context menu.

I'd still like the user to be able to disable top blocks though via the menu.

I'm proposing an option to allow the disable menu item to still be available for just these blocks.

Maybe a third value for disable, eg: 'onlyTop'?

Blockly.BlockSvg.prototype.showContextMenu_ would check for this and check whether the block was a 'top' block (in the same way that Blockly.Events.disableOrphans does) to determine whether to add the menu item.

I'd be happy to supply a PR for this if you feel it's something useful enough to add to the core.

I wonder if there was already an plan or discussion to integrate an kind of bitmap input ?

Example:
You have an 100x120 map, where you could active or deactivate an field with the mouse.
Depending on your choice it will output an multi-dimension array like (for 4x4):
[[1, 1, 1, 1, 1],
[1, 0, 1, 0, 1],
[1, 0, 1, 0, 1],
[1, 0, 1, 0, 1]]

The output could be used to draw something on small lcd screen.
The only settings for such an input block should be width and height.

Files and folders needed for a plugin template:

• eslintrc (unless we move it up a level)
• README
• package.json
• src/
• test/
• test/playground.html
• test/multi_playground.html
• webpack.config.js

• Move packages around
• Update their package.json
• Update READMEs
• Republish all plugins
• Update templates
• Updating issue templates (Question about what the feature request it is about)
• Move modern theme into a plugin
• Add browser support in package.json
• Move screenshot to devtools
• Typescript template?

Category

Codelabs

Component

Title: Create a Custom Theme

Describe the solution you'd like
A codelab in which the user creates a super spooky halloween theme for Blockly.

Sections:

• Codelab Overview
  • What you'll learn
  • What you'll build
• Setup
• Define Theme
• ???

Describe alternatives you've considered

Leave the documentation as-is.

Additional context

https://developers.google.com/blockly/guides/configure/web/themes

Is your feature request related to a problem? Please describe.
Testing all of the plugins with the current blockly version on develop would take a significant amount of time.

Describe the solution you'd like
A script and process that will make testing the blockly plugins a faster process than it currently is. This will probably include an easy way to link all the plugins to the current blockly version for testing.

Describe alternatives you've considered
Not testing until after we release.

Additional context

Category
Templates

Component

All templates

Describe the bug
Index.html currently contains this:

<body>
  <div id="blocklyDiv" style="height: 480px; width: 600px;"></div>
  <script src="../build/test_bundle.js"></script>
</body>

It should be bigger (800x800?) to make it easier to have more than a few blocks visible at a time, and so that widgets don't hit the edge of the workspace so easily.

Where is the prompt. Js file used?What does it do?

Problem statement

It can be hard to tell the full extent of a workspace, where the extent of the blocks on a workspace actually end. The scrollbars overshoot the workspace so as to allow extended beyond the visible limits but they aren't a good indicator of where the actual 'edge' is.

Expected Behavior

Some indication there are no more blocks above, below or to either side of what you are currently viewing.

An Idea

This idea sprung from a comment by @rachel-fenichel ... google/blockly#2205 (comment)

The background could provide this indication via change in colour/appearance when the edge of the existing blocks is reached.

Examples:

(Disclaimer: I'm no good with colour or svg styling, I'd expect we could come up with better styling in reality, maybe blurred edges etc)

This shows that the total extent of the workspace is just the blocks we see:

This shows that there are more blocks above & left of what we see:

One thing I'm aware of with this is that it may mislead the user into believing they can only drag within the highlighted area or drop new block into that - I imagine that could be overcome by fading the outer area to match the highlighted area when a drag operation starts, or to expand the highlighted area outwards.

Category
Plugin

Component

@blockly/plugin-backpack

Is your feature request related to a problem? Please describe.

App Inventor, Scratch, etc have backpacks. We should too!

Describe the solution you'd like

• The backpack should be a flyout that is either on the side opposite the toolbox, or on the bottom. (I'm open to arguments on which is best.)
• Like the trash can, it should be a target for drags.
• Dropping a block or block stack should add it into the backpack.
• There should be a button to open and close it.
  • Optionally positioned on the workspace? But this is secondary, because it can be added in the surrounding UI if necessary.
• Possibly also a right-click action to add a block or block stack to the backpack?

APIs required from core Blockly

• Register a drag target
• Either an API to get metrics or one to automagically position the flyout
• (Optional) Add button/control on workspace
• (Optional) Add Blockly-global context menu option

Repro steps:

1. Load the react demo.
2. Drag in a custom field.
3. Open the field, then close the field.

Currently, if the client does not get a confirmation that a write to the database was successful it will make the events as not sent and retry them with any new events at a later time.

This raises an issue where events may have been written successful, but the client missed the confirmation. In which case the client will resend the events and the database will have duplicate data.

Solution:

• Retry the events immediately.
• Batch events and keep track of their entryId on the client side. (#21)
• Implement logic in the server which allow it to know which data is duplicate by looking at the entryId of the batch of events. (#32)

I just remembered that the blockly dependency for the block-plus-minus package will need to be bumped after the next release because it relies on google/blockly#3814 for the procedures to work properly.

Maybe it can be bumped ahead of time? Not sure.

Just wanted to put up an issue to make sure this doesn't get lost!

A package containing dev blocks and toolboxes.

Open question: does this belong in the core blockly repo instead?

Category
Codelabs

Component

Title: Building a Third Party Plugin

Describe the solution you'd like

Sections:

• Codelab Overview
  • What you'll learn
  • What you'll build
• Setup
• Name your plugin
• Create your package
• Write your code
• Testing
• Update the README
• Publish
  • Tagging conventions

Describe alternatives you've considered

Putting more of this information in the README

Additional context

https://github.com/google/blockly-samples/tree/master/plugins/dev-create

Integrate https://lerna.js.org/ making it easier to bootstrap and publish packages.

Category

Plugins

Component

Part of dev-tools.

Is your feature request related to a problem? Please describe.

It's often helpful to download a screenshot of your blocks during development or debugging.

We have some code to do this in core Blockly. It's not ready to be published for users, but is ready to be used by developers.

Describe the solution you'd like

• Copy the contents of screenshot.js from the core Blockly repository
• Add a way to initialize it onto a workspace to put it in the context menu.

Desired functionality

• A context menu option on the workspace to download a screenshot of all blocks on the workspace.
• (optional) A context menu option on blocks to download a screenshot of the selected block (or block stack?)

APIs needed in core Blockly

• Possibly google/blockly#3237

Additional context

• google/blockly#2914
• google/blockly#3238
• Adding this to dev-tools doesn't remove the request to have it as a general-purpose plugin

Needs discussion

• API
• Tests

Move the test blocks from the playground, and the test block toolbox, into devtools.

Why: they're useful for testing all plugins, not just code in core.

We can still use them in the core playground with unpkg and a script tag.

Problem Statement

Often you want to access all the blocks with a specific "tag". For example: all procedure blocks, all call blocks for a specific procedure, all blocks of a particular type, all top blocks, etc.

Currently there are two ways of doing this:

1. Look through every block on the workspace to see if it has the tag.
2. Create an array on the workspace where you register these blocks.

Both of these approaches have problems. 1 is not very efficient, and 2 is not very extendable.

Proposal

Create functions on the workspace to support adding blocks to and accessing blocks from dynamic collections based on tags.

The structure for the collections object will be a dictionary of string keys that point to arrays of blocks. Each collection can have multiple blocks, and each block can be in multiple collections.

Add a function to the workspace named addBlockToCollection(block, collection).
This function will:

• Add a property to the collections object if the given collections key does not exist.
• Optional) Add the key to a keys array that can be used to check if a collection exists.
• Add the block to the collection array if it has not already been added.
• Pass back an object to / assign an object to the given block. This object will work similarly to event binding data, and can be used to easily remove the block from all collections when it is disposed.

Add a function to the workspace named removeBlockFromCollection(block, collection).
This function will (all of this is dependent on how addBlockToCollection works):

• Remove the block from the given collection array (if the array exists and the block is included).
• (Efficiency?) Remove the collection property from the collections object if the array is now empty. Also remove it from the tags array.
• Remove the collection data from the block if it was assigned directly instead of passed.

Add a function to the workspace named removeBlockFromAllCollections(block/bindData).
This function will:

• Use the bind data to remove the block from all collections, in a fasion similar to how events bindings work.

Add a function to the workspace named getBlocksInCollection(collection).
This function will:

• Return the blocks assigned to the given collection if it exists. Otherwise return an empty array.

If this proposal is accepted I think it may also be useful to set up some naming conventions for the tags. Maybe something like general category:specific tag. E.g. position:top, position:orphan, type:controls_if, caller:do_something.

Use Cases

I think this would be a useful addition to the blockly core because it would make the procedure code more efficient, but I also think it would be useful to outside developers.

Here are some use cases:

• Operations on custom procedure-like blocks (I had to create these for my application).
• Operations on blocks containing variables of different types.
• Accessing all blocks with a certain theme (this could also be used in the core).
• Collecting all colours used on the workspace to add "recently used colours" to a colour field.
• Any other time you see people looping through all of the blocks in a workspace.

Plus the things that are already provided i.e. top blocks, all blocks, and blocks by type, this just makes it more extendable and dynamic.

My projects often deal with text prediction / compression. Meaning I need to predict the next bit of the sentence. The "code" made during this is a long number and also needs to be made into a binary form to store the super long number. So there's a constant need to transform bytes to bits and back. I also find integer/float to text conversion commonly needed, and conversion back to integer/float too. These last steps in my project resulted in me having to finish the code in Python editor, instead of being fully shareable as blocks.

I see the create_text_with block can transform a number into a string type. It would be very useful to have such other similar block that convert string/integer(/float)/bit types to and from each other.

Perhaps you could create a switch for just Python if it won't work for all 5 languages.

The multiplayground in blockly core has lots of different directions for toolboxes, but choosing different configs would make it more useful. This would be published as part of the dev tools package and used in testing plugins.

Useful configs, each of which should be tested in LTR and RTL

• Simple flyout
• Toolbox
• No zoom

Category

Plugin

Component

@blockly/plugin-toolbox-search

Is your feature request related to a problem? Please describe.

It can be hard to find a block in the toolbox, even when you know which block you want.

Describe the solution you'd like

A Search category in the toolbox with a text field. The user types in the text field and the blocks in the flyout update in response.

Describe alternatives you've considered

The text field could be in either the category name or the flyout for the category.

Additional context

APIs needed in core Blockly:

• Ability to import a toolbox category and use it with your own toolbox
• (Possibly needed) Ability to add arbitrary UI elements in the toolbox category menu

See also:

• google/blockly#3851
• google/blockly#766

Bug report For the react example:
Expected: the example react app
Received: an error in the browser window after successful compilation:
BlocklyReactField.jsx:65 Uncaught TypeError: Cannot read property 'register' of undefined

65 | Blockly.fieldRegistry.register('field_react_component', BlocklyReactField);

(see below)

Reproduce:
ln the blockly-react directory run npm install; npm run start

BlocklyReactField.jsx:65 Uncaught TypeError: Cannot read property 'register' of undefined
    at Module../src/fields/BlocklyReactField.jsx (BlocklyReactField.jsx:65)
    at __webpack_require__ (bootstrap:781)
    at fn (bootstrap:149)
    at Module../src/blocks/customblocks.js (customblocks.js:1)
    at __webpack_require__ (bootstrap:781)
    at fn (bootstrap:149)
    at Module../src/App.js (App.css?4433:45)
    at __webpack_require__ (bootstrap:781)
    at fn (bootstrap:149)
    at Module../src/index.js (index.css?f3f6:45)
    at __webpack_require__ (bootstrap:781)
    at fn (bootstrap:149)
    at Object.0 (serviceWorker.js:135)
    at __webpack_require__ (bootstrap:781)
    at checkDeferredModules (bootstrap:45)
    at Array.webpackJsonpCallback [as push] (bootstrap:32)
    at main.chunk.js:1
./src/fields/BlocklyReactField.jsx @ BlocklyReactField.jsx:65
__webpack_require__ @ bootstrap:781
fn @ bootstrap:149
./src/blocks/customblocks.js @ customblocks.js:1
__webpack_require__ @ bootstrap:781
fn @ bootstrap:149
./src/App.js @ App.css?4433:45
__webpack_require__ @ bootstrap:781
fn @ bootstrap:149
./src/index.js @ index.css?f3f6:45
__webpack_require__ @ bootstrap:781
fn @ bootstrap:149
0 @ serviceWorker.js:135
__webpack_require__ @ bootstrap:781
checkDeferredModules @ bootstrap:45
webpackJsonpCallback @ bootstrap:32
(anonymous) @ main.chunk.js:1

TLDR

Blockly.inject() doesn't provide XML to the browser in either the Angular sample, or my own implementation based on it.

Concept Summary

I've built out a version of the Blockly Sample for Angular with a view to getting the Code Editor working inside it. In theory, this shouldn't require a lot more than injecting the appropriate XML, adding the code.js, and including some additional structure to the component HTML.

Angular Implementation

To implement this, I've created an Angular Service, calling a separate XML file, to supply the Blockly XML into the component - blockly.component.ts looks like this.

Chrome DevTools Error

What I'm seeing though is an error in the console, where line 405 of code.js says it can't find id="toolbox".

Looking at the HTML in the browser, it appears that the injected XML is missing from blocklyDiv, and all I'm seeing is a structure based on SVG elements.

Rendered App

In the browser window, this is what I'm seeing rendered. As you can see, the category names are not populating, due to the console error.

Current Workaround

The only way I've found to address the problem, is to render out the XML directly using...
const blocklyDiv = document.getElementById("blocklyDiv"); blocklyDiv.innerHTML = xml;
...where xml is a reference to the XML string itself, and cutting out the Blockly.inject() method altogether, which feels wrong and I think likely to catch me out later when I come to the point where I need to add custom blocks into the mix.

Google Blockly Sample - Angular

I've gone back to a clean copy of the Angular sample to understand what the behavior is there. Again, there is no sign of the XML structure, just the SVG one - and no id="toolbox" in the HTML.

At this point, I'm not sure whether I'm implementing things incorrectly, or whether there is a bug associated with Blockly.inject() when used in Angular.

Any suggestions?

Category

Plugins

Component

field-slider

Describe the bug

The slider field should inherit the parent block colour if it's a shadow block.

To Reproduce

Expected behavior

The slider colour should be the same as the parent.
Order of precedence should favour the parent block's color if it's a shadow block.

Screenshots

See above

Additional context

To work on this issue, first read the background information about how to contribute to samples and verify your changes.

The slider field sets its color in the showEditor_ function. Currently, it only checks the source block's color, but if the source block is a shadow block, this fails as shown above. To fix this, do the following steps:

1. Run npm run start in the field-slider plugin directory to start the playground.
2. In the right-hand configuration settings panel.
3. Drag one of the "parent" blocks out of the toolbox and click the number to open the slider field. Note how the colors are inconsistent.
4. Change the slider field's showEditor_ function to take into account if the block is a shadow block. You can check if it is with this.sourceBlock_.isShadow(). If it is a shadow block, then instead of setting the color to the source block's color, set it to the parent block's color. You can get the parent's block color with this.sourceBlock_.getParent().getColour().
5. Test your changes by repeating step 3 and ensuring the colors match now.

For more information about shadow blocks, see this page

The problem

The proposed dynamic variable getter and setter blocks (see google/blockly#1281) don't display the type of the selected variable, which will be confusing for users.

Possible solutions

1

Add dynamically update the text on the block to include the variable type (e.g. 'set string ___', 'set number ____', etc.).

We would have to consider internationalization implications.

This works for arbitrary numbers of variable types, but can make the blocks hard to read for users who aren't used to typed variables. They may see the variable type as a noun instead of an adjective, which will break the flow of the sentence.

2

Change the color of the block based on the type of the variable.

This would probably only work for a limited number of variable types, and could lead to confusion if there are conflicts with the colors of other categories of blocks. We could allow developers to specify colors for each type, but that requires an additional API.

Developers can accomplish the same thing by creating a similar block and adding an onchange handler with a lookup table for the colour, or by creating multiple getters and setters (one per variable type) with different colours for each block.

3

Add an icon to the block, and have it change based on the type of the variable.

This would require developers to specify icons per variable type, which requires an additional API.

Developers can accomplish the same thing by creating a similar block and adding an onchange handler with a lookup table for the icon, or by creating multiple getters and setters (one per variable type) with different icons on each block.

Is your feature request related to a problem? Please describe.

Search bar should select all when the bar is focused.

Describe the solution you'd like

Similar behaviour to other search bars, if there's content in the search bar, its selected so when a user types its replaced.

Steps to Reproduce

1. Navigate to the plugins/workspace-search directory.
2. Run npm run start.
3. Click on the search bar on the workspace, and type some text into it.
4. Click the workspace to unselect the search bar.
5. Click the search bar again.
6. Observe how the text you typed in is not selected, when it should be.

In order to allow broadcasting from the server to the clients, the server needs to know when new data has been added to the database.

Hi,

This project is quite the hidden little gem.

I was looking around, but I couldn't see anything about generating Go (golang) code. You have for Dart, Javascript, PHP and Python, but I think it would be pretty cool to also add Go support.

I'm sure the Go community would love that.

Any plans to add this support?

Thanks!

I drop print and string input block in board, and run below code method to execution, but somehow I don't know why 'code' seem like null, do we have example for execution blockly?

runJS() {
      Blockly.JavaScript.INFINITE_LOOP_TRAP = 'checkTimeout();\n';
      var timeouts = 0;
      var checkTimeout = function() {
        if (timeouts++ > 1000000) {
          throw MSG['timeout'];
        }
      };
      var code = Blockly.JavaScript.workspaceToCode(this.workspace);
      Blockly.JavaScript.addReservedWords('code,timeouts,checkTimeout');
      Blockly.JavaScript.INFINITE_LOOP_TRAP = null;
      try {
        eval(code);
      } catch (e) {
        alert(MSG['badCode'].replace('%1', e));
      }

Category
Plugin

Component

`@blockly/plugin-screenshot

Is your feature request related to a problem? Please describe.

Screenshots are a good way to communicate about code. We can generate a screenshot from within blockly.

Describe the solution you'd like

• A right click option on the workspace that lets you download a screenshot of the whole workspace.
• A right-click option on blocks that lets you download a screenshot of the given block.

Describe alternatives you've considered

Only allow screenshots of individual blocks.

APIs needed in core Blockly

• Possibly google/blockly#3237

Additional context

• google/blockly#2914
• google/blockly#3238
• #245 discusses a smaller project, which is adding it only as a developer tool

Needs discussion

• API
• Tests
• Cross-browser compatibility. The way it is currently implemented in core Blockly doesn't work on some browsers.

Category
Plugins

Component

@blockly/dev-tools

Is your feature request related to a problem? Please describe.

I want to be able to add and test a new theme or renderer in a playground that uses addGUIControls.

Describe the solution you'd like

Find all registered themes and renderers and add them to the corresponding dropdowns on GUI controls automatically.

Describe alternatives you've considered

Expose an API for setting what the dropdown values could be.

I was thinking, since you want to accept contributions to this repo, it would be cool to create some sort of "contributor welcome". I know that you have the CONTRIBUTING.md file, so maybe this could be an extension of that. Just a couple of sections that explain what kind of contributions you're interested in, how to get started, etc. What do you guys think? =)

To prepare for the use of websockets, the functions to write data from the server and to receive server updates should be separated.

Currently, every time the client writes data to the server it automatically triggers a query from the server as the primary way to get updates from the server.

In the future, websockets will replace the current endpoint API-based server and the primary way for a client to get updates will be via a broadcast that originates from the server rather than the client.

Scenario:

NOTE: all events are move events for a top level block with no connections.

Based on the current logic, Client 2 will need to undo Event B in order to get to a common root with the Server before applying the Event A and Event B in the correct order.

When Client 2 attempts to "undo" the event by running it in reverse, there is an error at Blockly Events, L514.

TypeError: Cannot read property 'nextConnection' of null

Add a Pull request template.

What do we want in there?

• Plugin / Example / Code lab
• ...
• ...

Questions from PR:
Should this also call workspace_.dispose as workspace search is usually wrapped around a workspace.
Need to dispose of event handlers.

As far as I can tell, Blockly always expects a floating point number to be represented using a period as the decimal character (e.g., 1.23). While Blockly seems to handle the text for other locales very well (word ordering & direction), it does not seem to handle locales that use the comma as a decimal character (e.g., 1,23).

(Please correct me if I'm mistaken, but I looked at the Localization page and there was no mention of it: https://developers.google.com/blockly/guides/create-custom-blocks/localize-blocks)

I would like support for customizing which decimal character to use, either by (in order of preference):

1. Some methodology to pass the desired decimal character to the Blockly code
2. Blockly querying the system's locale settings to determine the appropriate character
3. A means to allow the user to specify which character to use

Thank you for your consideration.

Several times I've found myself wanting to move multiple block groups at once when organizing my workspace (perhaps to make room for a new block group). My instinctive action is to attempt to drag a rectangle around the blocks, but this just drags the workspace.

I suggest we allow user to hold shift to change the drag behavior into creating a rectangular selection marquee.

This might be the default behavior on non-scrollable workspaces.

Category
Plugins.

Component

@blockly/eslint-config

Describe the bug

Eslint is peculiar about how it likes its config and where it looks for eslint plugins (eslint-config-google, @typescript-eslint, etc).

We want to have third party plugins using @blockly/dev-scripts to get our eslint configs so npm run lint and editor linting would work. That leads us to creating our own eslint sharable plugin (@blockly/eslint-config).

It gets a little more tricky because we (for first party plugins), use lerna, which doesn't install package "dependencies" in a plugin that depends on a locally linked package. It only installs a symlink to that package, so adding @blockly/eslint-config isn't sufficient for editor eslint to work.

Options:

• Create the eslint-config outside of the plugins folder and have it published separately.
  That would have lerna plugins and third party plugins using the same eslint configuration.

• Use a different eslint setup for first party vs third party plugins, and keep all eslint plugins installed in blockly-samples's package root.

how can i add blockly jr to this project?

Problem Statement

ReadMe does not have a documentation on the rtc sample or the rendering sample.

Proposed solution:

Add a one line description bullet e.g:

• blockly-requirejs-sample: Loads RequireJS from a CDN and loads Blockly using AMD.

for the rtc and rendering samples. It should be placed in the top section of the readme.

Files and folders needed for a block template:

In the blocks folder:

• eslintrc

In each block's subfolder:

• package.json
• src/
• test/

Where it lives: packages/plugins/
What it contains:

 env => {
    return {
        target: 'web',
        mode: env.mode,
        entry: './src/index.js',
        devtool: 'source-map',
        module: {
            rules: [{
                test: /\.js$/,
                exclude: /(node_modules)/,
                use: {
                    loader: "babel-loader",
                    options: {
                        presets: ["@babel/preset-env"]
                    }
                }
            }]
        },
        devServer: {
            openPage: 'test',
            port: 3000,
            open: true
        },
        externals: {
            'blockly/core': {
                root: 'Blockly',
                commonjs: 'blockly/core',
                commonjs2: 'blockly/core',
                amd: 'blockly/core'
            },
        }
    }
};

Open question:
Do we pick a standard output and include it, or require each package to add it? Sample output:

        output: {
            path: path.resolve(__dirname, 'dist'),
            publicPath: '/dist/',
            filename: 'typed-modal.umd.js',
            libraryTarget: 'umd',
            globalObject: 'this'
        },

I'd like to introduce blocks wich return promises and should be awaited.

For this, in Codegeneration every function should be prefixed by an "async " so promises could be awaited inside it. And also Procedure or function calls should be awaited.

I'd like to introduce a setting with async support, so it could be used.

Will a pull req. for this be accepted?

The Plane demo currently uses soy templates and closure to do language swapping. That's not especially interesting anymore, but we could adapt it to do the same thing but with our preferred way of swapping languages. We could also have live theme swapping in the same demo.

update: the plane demo has been deleted. it would still be useful to have a demo of live swapping languages/themes/etc.