The keen npmjs.com watches amongst you (hi, @dependabot!) will have noted that, since the last publicly-announce beta, v11.0.0-beta.1, there have been two additional betas published to npmjs.com. These were created to facilitate development and testing of work in the blockly-samples repository, and all the changes from those two unpublicised releases are rolled into the changelist below.
exports
directive in package.json
The most important change in v11.0.0-beta.4 is actually a change to the packaging, rather than the contents of the package.
Specifically, we have added an exports
directive, to the package.json
file, which definitively enumerates the valid entrypoints for the package. The purpose of this change is to prepare for the publication of ES module entrypoints, that will supplement (and ultimately supplant) the existing CommonJS module entrypoints, in future versions of Blockly.
Adding an exports
section:
blockly/javascript
); without exports
all subpath entrypoints must be either ESM or CJS and it is not possible to provide both.Module resolution is ultimately at the discretion of each JS runtime or build tool. Browsers, node.js, Webpack, Closure Compiler, etc. each have their own module resolution and loading implementations. The package.json
file was originally for the benefit of npm
in its role of installing packages and their dependencies, but now contains additional information (like the browser
, exports
, main
, umd
, and unpkg
directives) that are honoured to varying degrees by different tools. It is therefore hard to say categorically what file(s) will be loaded by which tools without consulting each tool's documentation (and/or implementation), but amongst tools that have some kind of support for NPM packages, the exports
directive appears to be widely and consistently supported.
Here is some of the relevant documentation for tools we expect Blockly developers are likely to use:
package.json
exports
support and module resolution and loaders.BREAKING CHANGE: The introduction of an exports
directive means that correctly-behaved tools (node.js, bundlers like webpack, etc.) will only allow importing of the specified entrypoints. Here is the full list of permitted entrypoints that can be import
ed or require
d:
blockly
blockly/core
blockly/blocks
blockly/dart
blockly/lua
blockly/javascript
blockly/php
blockly/python
blockly/msg/<lang>
, for all supported language codes <lang>
(e.g blockly/msg/en
, blockly/msg/fr
, blockly/msg/de
, etc.)If you previously imported any other paths from the blockly package you will need to update your imports. Here are the most common paths that may have been used, and their correct replacements:
If you previously imported: | Import instead: |
---|---|
blockly/index.js | blockly |
blockly/node.js | blockly |
blockly/browser.js | blockly |
blockly/blockly.min | This file should only be loaded as a <script> . |
blockly/core.js | blockly/core |
blockly/core-browser.js | blockly/core |
blockly/blockly_compressed.js | blockly/core |
blockly/blocks.js | blockly/blocks |
blockly/blocks_compressed.js | blockly/blocks |
blockly/dart.js | blockly/dart |
blockly/dart_compressed.js | blockly/dart |
blockly/lua.js | blockly/lua |
blockly/lua_compressed.js | blockly/lua |
blockly/javascript.js | blockly/javascript |
blockly/javascript_compressed.js | blockly/javascript |
blockly/php.js | blockly/php |
blockly/php_compressed.js | blockly/php |
blockly/python.js | blockly/python |
blockly/python_compressed.js | blockly/python |
blockly/msg/en.js | blockly/msg/en |
If you are loading Blockly as a script you should continue to load the compiled chunks (blockly_compressed.js
, blocks_compressed.js
, javascript_compressed.js
, etc.) directly, or load blockly.min.js
which is just a concatenation of blockly_compressed.js
, msg/en.js
, blocks_compressed.js
, and javascript_generator.js
.
(Prior to v11 there were various entrypoint wrappers provided in the form of UMD modules (e.g. blockly.js
, javascript.js
, etc.) but loading these as as scripts never did anything useful and, as they are no longer needed, they have been deleted.)
BREAKING CHANGE: Prior to v11, importing the main blockly
package would import blockly/core
, blockly/blocks
, blockly/msg/en
and blockly/javascript
—and additionally, in node.js
, also blockly/dart
, blockly/lua
, blockly/php
and blockly/python
.
Now the main blockly
package entrypoint never loads any of the generators.
This change has been made because of changes to generator exports made in blockly v9.0.0 that make necessary to always separately import generator modules in order to use them.
Note that this change does not affect loading the blockly package via <script src="https://unpkg.com/blockly">
; that continues to load to blockly.min.js
, which continues to include javascript_compressed.js
which (when loaded as a script) makes itself available via Blockly.JavaScript
for backwards compatibility.
BREAKING CHANGE: The angle, colour and multiline input fields (FieldAngle
, FieldColour
and FieldMultilineInput
respectively) have been deleted from Blockly. All three are now provided as plugins. The blocks associated with the colour field and multiline text field have been moved to the field plugins, which now provide documentation on how to install the blocks.
BREAKING CHANGE: Code emitted by the LuaGenerator
now uses nil
instead of None
. This may break some user's downstream block programs if they are assigning to a variable called None
and then initializing lists with empty inputs expecting them to contain the value assigned to None
.
There were also breaking changes to block disposal and to certain CSS classes, as well as other changes made for v11 and/or rolled up from v10; see below for the complete list.
exports
section in package.json
by @cpcallen in #7822scrub_
public
by @cpcallen in #7940Full Changelog: blockly-v11.0.0-beta.1...blockly-v11.0.0-beta.4
All changes to date in v11:: blockly-v10.4.3...blockly-v11.0.0-beta.4