Set "type": "commonjs" in the generated dist/package.json file,
since the .js files in the package root are CJS. This should be a
no-op since that's the default, but by setting it explicitly we
ensure that any change to the repository top-level
package.json to set "type": "module" won't break the
published package accidentally.
* feat(build)!: Introduce ESM entrypoints for chunks
Introduce an "import" conditional export for each of the chunk
entrypoints (blockly/core, blockly/blocks, blockly/javascript
etc.), and point these at wrappers created by build_tasks.js
that import the corresponding <chunk>_compressed.js file and
export its named exports.
BREAKING CHANGE:
Importing Blockly via
import Blockly from 'blockly/core';
(and similarly for the other chunk entrypoints) has worked until
now because most build tools (including Webpack in particular)
fuilfil the request for the default export of a CJS module by
providing the module.exports object, rather than an
explicitly-named default export as they would for an ES module.
Since core/blockly.ts (the notional entrypoint for blockly/core)
does not provide a default export, the wrappers created by this
PR do not either.
Code of the above form will therefore break, and should be updated
to use a wildcard:
import * as Blockly from 'blockly/core';
* feat(build)!: Introduce main package ESM entrypoint
Introduce an "import" conditional export for the top-level
package entrypoint (blockly), and point it at a wrappers
created by build_tasks.js that imports the existing index.js
file.
BREAKING CHANGE:
Importing Blockly via
import Blockly from 'blockly';
has worked until now because most build tools (including Webpack
in particular) fuilfil the request for the default export of a
CJS module by providing the module.exports object, rather than an
explicitly-named default export as they would for an ES module.
Since core/blockly.ts does not provide a default export, the
wrapper created by this PR does not either.
Code of the above form will therefore break, and should be updated
to use a wildcard:
import * as Blockly from 'blockly';
* feat(build)!: Introduce ESM entrypoints for langfiles
Introduce an "import" conditional export for each of the
langfile entrypoints (msg/en, msg/fr, etc.),, and point them
at wrappers created by build_tasks.js that import the
existing <lang>.js file.
BREAKING CHANGE:
Importing languages via
import en from 'blockly/msg/en';
has worked until now because most build tools (including Webpack
in particular) fuilfil the request for the default export of a
CJS module by providing the module.exports object, rather than an
explicitly-named default export as they would for an ES module.
Code of the above form will therefore break, and should be updated
to use a wildcard:
import * as en from 'blockly/msg/en';
* fix(typings): Remove bogus .d.ts file.
For some reason we had a typings/msg/yue.d.ts that did not
correxpond to any msg/json/yue.json. Delete it.
* feat: allow prompt to take in additional params
* feat: allow confirm tot ake in extra args
* feat: allow alert dialog to take in extra parameters
* chore: add tests for dialog methods
* Correct list's "find" and "get" blocks help.
Both blocks were using the same help URL.
Two unrelated results of recompiling messages:
* Allow unwanted 'qqq' messages to be reverted.
* 'constants.json' is unchanged, but sorted.
Also improve python json dumping.
This is in effect a partial rollback of PR #7822.
This should solve issues encountered by users of bunders that don't
support exports at all (e.g. browserify) as well as ones that don't
support it in certain circumstances (e.g., when using webpack's
resolve.alias configuration option to alias 'blockly' to
'node_modules/blockly', as we formerly did in most plugins, which
causes webpack to ignore blockly's package.json entirely).
Assumptions:
- Such bundlers will _completely_ ignore the exports declaration.
- The bundles are intended to be used in a browser—or at least not
in node.js—so the core entrypoint never needs to route to
core-node.js. This is reasonable since there's little reason to
bundle code for node.js, and node.js has supported the exports
clause since at least v12, considerably older than any version of
node.js we officially support.
- It suffices to provide only a CJS entrypoint (because we can only
provide CJS or ESM, not both. (We could in future switch to
providing only an ESM entrypoint instead, though.)
* feat: Invalid Blocks
* Rename the new json property from invalid to invalidReasons.
* Merged isValid into isEnabled.
* Minor fixes.
* More minor fixes.
* Reverting some stuff that didn't need to change.
* Addressing PR feedback.
* Update the BlockInfo interface to match State.
* Make BlockChange.disabledReason private.
* feat: add context menu support and migrate easy options
* feat: pass events to context menu options
* chore: migrate final comment context menu option
* feat: add exports for comment context menu items
* chore: PR comments
