46df7d132d
* refactor(tests): Move and rename prepare.js, blockly.mjs
Since prepare.js and blockly.mjs are going to be needed for running
all tests in uncompiled mode (not just the playgrounds), move them
tests/. Further, rename prepare.js to bootstrap.js to better reflect
its purpose.
* feat(tests): Introduce BLOCKLY_BOOTSTRAP_OPTIONS
Provide a mechanism for web pages that use bootstrap.js to control
what is loaded and how.
* fix(tests): Use the blockly repository path for all script src= URLs
Previously the (non-advanced) playground was only correctly loadging
on localhost because you can put an arbitrary number of "../"s in front
of a relative URL and it just takes you to the root directory.
* fix(tests): Don't use template literals in bootstrap.js
This is necessary (but not necessarily sufficient) to be able to
load the file in IE 11.
* fix(tests): Throw error if attempting to bootstrap in node.js
* feat(tests): Make bootstrap.js more configurable.
* Terminology change: use "compressed" and "uncompressed" to describe
what Closure Compiler calls "compiled" and "uncompiled", to reduce
confusion with the compilation that will be done by tsc.
* Get the list of modules to bootstrap (in compressed mode), or
scripts to load (in compressed mode) from BLOCKLY_BOOTSTRAP_OPTIONS,
to allow calling scripts to to specify exactly what to load.
* feat(tests): Use a proper quote function
We need to generate string literals. Best to use a quote function
instead of concatenating on quote marks withou escaping. Copy a
well-tested one from Code City.
* feat(tests): Support an additionalScripts option
This is a list of scripts to load (in order) once the required modules
have been bootstrapped.
We do this using goog.addDependency to make the first script depend
on the required modules, then each subsequent script depend on the
previous one, and then finally goog.bootstrapping the last such script.
* refactor(tests): Remove special handling of msg/messages.js
* refactor(tests): Use additionalScripts for all script loading
Use additionalScripts option for all script loading in
playground.html and advanced_playground.html.
* refactor(tests): Use bootstrap instead of uncompressed in Mocha tests
Use tests/bootstrap.js instead of blockly_uncompressed.js to load
blockly in uncompressed mode in the Mocha tests.
This entails adding a new item, despFiles, to BLOCKLY_BOOTSTRAP_OPTIONS,
to allow tests/deps.mocha.js to be loaded at the appropriate point.
Mention of blockly_uncompressed.js is removed from
tests/mocah/.mocharc.js; it's not clear to me what effect the "file:"
directive in this file might have previously had and I was not able to
find documentation for it on mochajs.org, but in any case removing it
appears to have had no ill effect.
* refactor(tests): Use bootstrap instead of uncompressed in generator tests
This entails adding an additional check in bootstrap so as to load
uncompressed when loading from a file: URL, since these are not
localhost URLs - though in fact the generator tests run equally well
in compressed mode, albeit against (for now) the previously-check-in
build products rather than the live code.
* refactor(test): Use bootstrap.js in multi_playground.html
This removes the last use of load_all.js, so remove it.
* chore(tests): Delete blockly_uncompressed.js
Its function has now been entirely subsumed by tests/bootstrap.js,
so remove it and update any remaining mentions of it.
Also fix formatting and positions of some comments in playground.html.
* fix(tests): Rewrite bootstrap sequencing code
An earlier commit modified the generated <script> to use
goog.addDependency to trick the debug module loader into loading
.additionalScripts (via goog.bootstrap), but it turns out there is
a small problem: scripts like msg/messages.js have undeclared
dependencies on the Blockly module, and without a call to
goog.require('Blockly') in them they can end up being run before
the Blockly module is fully loaded.
(This problem only occurs when there are ES Modules, rather than
merely goog.modules, in the mix.)
Fix this by adding a script, bootstrap_helper.js, to be loaded
options.requires and any options.additionalScripts that makes an
explicit call to goog.require for each of option.requires.
Also refactor the code so that instead of generating a loop which
calls goog.addDependency, we generate the addDependency calls
directly. This makes debugging a bit easer as we can use the browser's
dev tools to inspect the generated calls in the DOM tree.
* fix(tests): Prevent spurious transpilation warnings
For some reason when the debug module loader encounters ES modules
it starts to complain about being unable to transpile some ES202x
features in other (non-ESM) modules, even though it doesn't normally
try to transpile those.
Since uncompressed-mode testing is almost exclusively on modern
browsers we don't care about transpiling these features, so suppress
the warnings instead.
* refactor(tests): Rename blockly.mjs to bootstrap_done.mjs; simplify
Since blockly.mjs is no longer returning just the exports object
from core/blockly.js (see PR #5995), it might be better named after
its actual purpose: to wait for bootstrapping to be done.
Remove all the code that was used to pass the blockly.js exports
object along from the bootstrap callback to the blockly.mjs export,
since there's no reason to go to a lot of trouble to set a local
variable named Blockly to the same value as a global variable named
Blockly.
(Something like this may be needed again in future, but certainly in
a different form.)
* chore(tests): Use freshly-build files in compressed mode.
Use the freshly-built build/*_compresssed.js files when bootstrapping
in compressed mode, rather than using the checked-in files in the
repository root.
This helps ensure that compressed and uncompressed mode will be
testing (as closely as possible) the same code.
* chore(tests): Rename BlocklyLoader to blocklyLoader; record compressed
- Rename the BlocklyLoader global to blocklyLoader (since it is not
a class constructor).
- Create it regardless of whether we are bootstrapping in
uncompressed or loading compressed via <script> tags.
- Record which we are doing as .compressed, and use this property
to choose playground background colour.
* chore(tests): Resolve comments for PR #6214
Mostly documentation changes, but notably renaming blocklyLoader to
bootstrapInfo.
* Revert "chore(tests): Use freshly-build files in compressed mode."
This reverts commit de8d356838.
Blockly 
Google's Blockly is a library that adds a visual code editor to web and mobile apps. The Blockly editor uses interlocking, graphical blocks to represent code concepts like variables, logical expressions, loops, and more. It allows users to apply programming principles without having to worry about syntax or the intimidation of a blinking cursor on the command line. All code is free and open source.
Getting Started with Blockly
Blockly has many resources for learning how to use the library. Start at our Google Developers Site to read the documentation on how to get started, configure Blockly, and integrate it into your application. The developers site also contains links to:
Help us focus our development efforts by telling us what you are doing with Blockly. The questionnaire only takes a few minutes and will help us better support the Blockly community.
Installing Blockly
Blockly is available on npm.
npm install blockly
For more information on installing and using Blockly, see the Getting Started article.
Getting Help
- Report a bug or file a feature request on GitHub
- Ask a question, or search others' questions, on our developer forum. You can also drop by to say hello and show us your prototypes; collectively we have a lot of experience and can offer hints which will save you time. We actively monitor the forums and typically respond to questions within 2 working days.
blockly-samples
We have a number of resources such as example code, demos, and plugins in another repository called blockly-samples. A plugin is a self-contained piece of code that adds functionality to Blockly. Plugins can add fields, define themes, create renderers, and much more. For more information, see the Plugins documentation.
Contributing to Blockly
Want to make Blockly better? We welcome contributions to Blockly in the form of pull requests, bug reports, documentation, answers on the forum, and more! Check out our Contributing Guidelines for more information. You might also want to look for issues tagged "Help Wanted" which are issues we think would be great for external contributors to help with.
Releases
The next major release will be during the last week of March 2022.
We release by pushing the latest code to the master branch, followed by updating the npm package, our docs, and demo pages. We typically release a new version of Blockly once a quarter (every 3 months). If there are breaking bugs, such as a crash when performing a standard action or a rendering issue that makes Blockly unusable, we will cherry-pick fixes to master between releases to fix them. The releases page has a list of all releases.
Releases are tagged by the release date (YYYYMMDD) with a leading major version number and a trailing '.0' in case we ever need a major or patch version (such as 2.20190722.1). Releases that have breaking changes or are otherwise not backwards compatible will have a new major version. Patch versions are reserved for bug-fix patches between scheduled releases.
We now have a beta release on npm. If you'd like to test the upcoming release, or try out a not-yet-released new API, you can use the beta channel with:
npm install blockly@beta
As it is a beta channel, it may be less stable, and the APIs there are subject to change.
Branches
There are two main branches for Blockly.
master - This is the (mostly) stable current release of Blockly.
develop - This is where most of our work happens. Pull requests should always be made against develop. This branch will generally be usable, but may be less stable than the master branch. Once something is in develop we expect it to merge to master in the next release.
other branches: - Larger changes may have their own branches until they are good enough for people to try out. These will be developed separately until we think they are almost ready for release. These branches typically get merged into develop immediately after a release to allow extra time for testing.
New APIs
Once a new API is merged into master it is considered beta until the following release. We generally try to avoid changing an API after it has been merged to master, but sometimes we need to make changes after seeing how an API is used. If an API has been around for at least two releases we'll do our best to avoid breaking it.
Unreleased APIs may change radically. Anything that is in develop but not master is subject to change without warning.
Issues and Milestones
We typically triage all bugs within 2 working days, which includes adding any appropriate labels and assigning it to a milestone. Please keep in mind, we are a small team so even feature requests that everyone agrees on may not be prioritized.
Milestones
Upcoming release - The upcoming release milestone is for all bugs we plan on fixing before the next release. This typically has the form of year_quarter_release (such as 2019_q2_release). Some bugs will be added to this release when they are triaged, others may be added closer to a release.
Bug Bash Backlog - These are bugs that we're still prioritizing. They haven't been added to a specific release yet, but we'll consider them for each release depending on relative priority and available time.
Icebox - These are bugs that we do not intend to spend time on. They are either too much work or minor enough that we don't expect them to ever take priority. We are still happy to accept pull requests for these bugs.
Good to Know
- Cross-browser Testing Platform and Open Source <3 Provided by Sauce Labs
- We support IE11 and test it using BrowserStack