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.)
* fix(typings): Remove bogus .d.ts files; add new languages
PR #3821 added .d.ts files for every file in msg/json/, but several
of these are internal utility files rather than translations, and
do not result in a langfile being output by create_messages.py
when building langfiles.
In the meantime we have added a few new languages that are being
published but which have (until now) not had the corresponding
type declarations.
* feat(build)!: Add exports section to package.json
Add an exports stanza to package.json, enumerating existing
entrypoints in a new format.
- The original main entrypoint, index.js, is removed since the
exports section can point directly at node.js or browser.js.
- No change made (yet) to other entrypoints (core, blocks,
generators); these will be dealt with in a subsequent PR.
- The msg/en entrypoint is included in the top-level package.json
as an example; entries for all other languages created as part
of the packageJSON package task.
BREAKING CHANGE: The introduction of an exports stanza 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 imported
or required:
- 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 impored 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 |
* fix(build): Use package-paths (blockly/*) in wrapper imports
Use 'blockly/core' instead of './core' when importing core into
other wrappers (and similarly for other entries in package.json
exports stanza), so that (e.g.) dist/javascript.js won't
import dist/core.js (the node.js version that loads jsdom) when
being loaded in a browser environment.
This fixes an issue where blockly attempts to load jsdom even
in browser environments because the browser stanza in
package.json, which caused attempts to load core.js to load
core-browser.js instead in browser environments, was removed
in a previous commit.
* refactor(build): Remove unnecessray wrappers
Remove pointless wrapper modules that no longer server any
purpose; use exports stanza in package.json to point directly to
compiled chunks where possible.
* refactor(build)!: Eliminate separate browser and node entrypoints
Combine scripts/package/browser/index.js (becomes dist/browser.js)
and scripts/package/node/index.js (becomes dist/node.js) into
a single environment-agnostic index.js.
BREAKING CHANGE: Historically, importing the main 'blockly' package
would import 'blockly/core', 'blockly/blocks', 'blockly/en' and
'blockly/javascript' - and additionally, in node.js, also import
'blockly/dart', 'blockly/lua', 'blockly/php' and 'blockly/python'.
Now the main 'blockly' package entrypoint never loads any of the
generator modules.
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.
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 includes javascript_compressed.js
and (due to being loaded as a script) makes it available via
Blockly.JavaScript.
* refactor(build): Simplify core entrypoint wrapper for node.js
Move scripts/package/node/core.js to scripts/package/core-node.js,
and have it packaged as dist/core-node.js rather than dist/core.js
- without a UMD wrapper, since it will always be loaded as a CJS
module.
* chore(build): Remove disused packageCommonJS helper
* refactor(build): Use subpath pattern (wildcard) for msg/* exports
Use a subpath pattern (wildcard) for the msg/* entrypoints,
obviating the need for special handling in packageJSON.
* fix(tests): Fix node tests
run_node_test.js previously directly require()d the dist/blockly.js
and dist/javascript.js wrapper module, which no longer exist.
Change it to require('blockly-test') (and …blockly-test/javascript)
and create a symlink ./node_modules/blocky-test -> dist/ to satisfy
this.
* fix(build): Add types: and default: entries to exports['./core']
In the 'blockly/core' export:
- Replace the browser: entrypoint with a default: one.
- Add a types: entrypoint for core.
* fix(node): Don't use global variables for jsdom injection
Introduce a (hopefully generally applicable) mechanism for
injecting dependencies into modules, specifically in this case
to inject required bits of JSDOM's Window and Document
implementations into core/utils/xml.js when running in
node.js or other environments lacking a DOM.
The injectDependencies function uses an options object to
facilitate optionally injecting multiple named dependencies
at the same time.
Rename the xmlDocument local variable back to document (was
renamed in #5461) so that the name used in this module
corresponds to the usual global variable it replaces.
Change the injection in scripts/package/node/core.js to use
injectDependencies instead of setXmlDocument + global variables;
also eliminate apparently-unnecessary creation of a special
Document instance, using the default one supplied by jsdom
instead.
Fixes#6725.
* deprecate(xml): Deprecate getXmlDocument and setXmlDocument
Mark getXmlDocument and setXmlDocument as @deprecated, with
suitable calls to deprecation.warn().
There are no remaining callers to either function within core -
setXmlDocument was only used by the node.js wrapper, and and
apparently getXmlDocument was never used AFAICT - and we do not
anticipate that either were used by external developers.
* fix: Corrections for comments on PR #6764.
* chore: regen msg dts files
* fix: package tasks not packaging msg.d.ts files
* fix: add setLocale to blockly.ts
* chore: format
* chore: move setLocale
* chore: add comment about setLocale not being useful when used with script tags
* chore: format
* fix: loading messages in the browser
* chore: fix comment
* fix: change unwrapped message files to write to a new object, rather than Blockly.Msg
* fix: fixup exports
* fix: PR comments
* fix: change to use for-in loop
* fix: ES6 compatibility and formatting
* chore: Clean up NPM package module wrappers
- Slightly improve documentation for each file based on helpful
explanations given by @samelhusseini.
- Removed redundant code---e.g., loading `javascript_compressed.js`
creates and sets Blockly.JavaScript as a side effect, so there is
no need to set `Blockly.JavaScript = BlocklyJavaScript` in
`dist/javascript.js` (generated from `scripts/package/javascript.js`).
- Remove possibly harmful code---e.g., `Blockly.Msg` is initialised
with a null-prototype object in `blockly_compressed.js` and that
initial object should under no circumstances be replaced.
- Remvoe downright misleading code---e.g., `dist/blocks.js` previously
_appeared_ to replace Blockly.Blocks with an empty object, but in
fact the `Blockly` name referred at that point to the exports object
from `blocks_compressed.js`, which would randomly get a useless
`{}`-valued `.Blocks` property tacked on to it; similarly, code in
`dist/browser.js` (generated from `scripts/package/browser/index.js`)
appeared to copy definitions from `BlocklyBlocks` to `Blockly.Blocks`,
but the former would always be (the aforementioned) empty object,
making this code ineffective.
* chore: Improve chunk definition / UMD generation
Make several improvements to the chunks global and chunkWrapper
function:
- Document chunk definition format (and improve the names of
of the documented properties).
- Replace the chunk `.namespace` property with two others:
- `.exports` names the variable/property to be returned by the
factory function, and which will be set on the global object if
the module is loaded in a browser.
- `.importAs` names the parameter that this chunk's exports value
is to be passed to the factory function of other chunks which
depend on this one. (This needs to be different because e.g.
`Blockly.blocks` is not a valid parameter name.)
- Change the definition for the blocks chunk to export Blockly.Blocks
(i.e., the block definition dictionary) as blocks_compressed.js
did previous to PR #5721 (chunked compilation), rather than the
(empty and soon to vanish) Blockly.blocks namespace object.
This is a win for backwards compatibility, though it does mean that
if we want to expose the `loopTypes` export from `blocks/loops.js`
we will need to find a different way to do so.
This is part of #5153 but is being prioritised because we want remove
the declareLegacyNamespace calls from the core/utils/*.js modules and
then reexport them explicitly via utils.js, and it turns out that
doing so results in the exports object of this module being passed to
Object.freeze - which fails on the global object, which can't be made
non-extensible!
The new name chosen for the former default export is globalThis, since
it is intended to have the same value as the global variable of that
name; see:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/globalThis
