Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Import fails

145 views
Skip to first unread message

Max Stephen Russell

unread,
Jan 8, 2025, 5:15:09 PMJan 8
to Blockly
In my main.js I have

// Import Blockly core.
import * as Blockly from 'blockly/core';
// Import the default blocks.
import * as libraryBlocks from 'blockly/blocks';
// Import a generator.
import {javascriptGenerator} from 'blockly/javascript';
// Import a message file.
import * as En from 'blockly/msg/en';
Blockly.setLocale(En);

When I switch from script tags to these imports, my workspace disappears. For libraryBlocks and javascriptGenerator, VS Code tells me each "is declared but its value is never read."

I am a beginner with Webpack, and package.json etc., but after looking long and hard at these and other files, I thought I'd ask, Can someone offer me a suggestion as to how to proceed with troubleshooting imports?

Thank you.

Steve



Mark Friedman

unread,
Jan 8, 2025, 6:05:43 PMJan 8
to blo...@googlegroups.com
Steve,

  Note that the method for accessing various Blockly objects/APIs is a little different when you load Blockly via imports than when you load them via script tags (see here), so if you are now using imports you'll need to use:
  • libraryBlocks rather than Blockly.libraryBlocks
  • javascriptGenerator rather than javascript.javascriptGenerator
  Also note that if you have other JavaScript files that access Blockly objects/APIs you'll need to put imports in those files as well.

  Hope this helps.

-Mark


--
You received this message because you are subscribed to the Google Groups "Blockly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blockly+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/blockly/7ec024eb-bfde-4d0c-a050-77143c2d091fn%40googlegroups.com.

Max Stephen Russell

unread,
Jan 8, 2025, 6:17:03 PMJan 8
to blo...@googlegroups.com
Thank you, Mark. I actually have two main things on my mind as I finally start to build my app. 1. Why am I not producing a workspace with these import statements? And 2. How exactly does a person decide if their project would be satisfied with script tags instead of imports? I’ve read repeated general explanations, but nothing yet specific enough to convince me either way.

-Steve

Max Stephen Russell

unread,
Jan 8, 2025, 9:36:22 PMJan 8
to blo...@googlegroups.com
I do understand the potential benefits of import over script tags. That’s why I am trying to get it working. In the meantime, I will rely on script tags so I can get moving. Eventually the little hangup that I’m not yet seeing will be revealed, and then I will switch to importing. So I’m satisfied for now but will definitely be receptive to any tips for troubleshooting the import impasse. Thanks.

-Steve

Christopher Allen

unread,
Jan 9, 2025, 8:31:45 AMJan 9
to blo...@googlegroups.com
Hi Max,
 
Thank you, Mark. I actually have two main things on my mind as I finally start to build my app. 1. Why am I not producing a workspace with these import statements?

If you previously had a working app, and it broke when you replaced script tags with imports, then you should look in the JS console: there will be error messages there which will indicate what the problem is (but not necessarily how to solve it).  If the messages you see don't lead you to the solution, share them here and I'm sure we, Mark or another forum user will be able to help.
 
2. How exactly does a person decide if their project would be satisfied with script tags instead of imports?

There are a variety of reasons one might choose one way or the other, but my advice is pretty simple:
  • Are you using some kind of bundler, like webpack or Closure Compiler?  If so, go ahead and use import: doing so now will make your life easier in future.
  • If not, you will not be able to use import and you must use <script src=…> instead.  This will eventually be fixed, but it will break backward compatibility with most other ways of loading Blockly (e.g. using <script> tags without type="module") so we've been holding off on it until ecosystem support (and demand) for ESM modules is more mature.  (We've probably reached that point now, but alas we're a bit short-staffed presently and have opted to focus on accessibility work that is a high priority for many of our partners for reasons such as this.)
In the meantime, I will rely on script tags so I can get moving. Eventually the little hangup that I’m not yet seeing will be revealed, and then I will switch to importing.

A good plan.


Best wishes,

Christopher

Max Stephen Russell

unread,
Jan 9, 2025, 12:44:01 PMJan 9
to Blockly
I'm getting an error that seems to have stricken many a programmer, with many fixes suggested and none of which has helped me.

ERROR in ./main.js 2:0
Module parse failed: 'import' and 'export' may appear only with 'sourceType: module' (2:0)
File was processed with these loaders:
 * ./node_modules/babel-loader/lib/index.js
You may need an additional loader to handle the result of these loaders.
| // Super Simple Test, Testing import

> import * as Blockly from 'blockly/core';
| import * as libraryBlocks from 'blockly/blocks';
| import { javascriptGenerator } from 'blockly/javascript';

====

main.js:
// Super Simple Test, Testing import
import * as Blockly from 'blockly/core';
import * as libraryBlocks from 'blockly/blocks';
import {javascriptGenerator} from 'blockly/javascript';
import * as En from 'blockly/msg/en';

I'd be happy to hear a suggestion for addressing this error.

Thanks.

Steve
Max Stephen Russell

Mark Friedman

unread,
Jan 9, 2025, 2:12:11 PMJan 9
to blo...@googlegroups.com
On Wed, Jan 8, 2025 at 3:17 PM Max Stephen Russell <maxsr...@gmail.com> wrote:
Thank you, Mark. I actually have two main things on my mind as I finally start to build my app. 1. Why am I not producing a workspace with these import statements?

That's hard to say without seeing your code.  Can you post the code or a link to a repo containing the code?

And 2. How exactly does a person decide if their project would be satisfied with script tags instead of imports? I’ve read repeated general explanations, but nothing yet specific enough to convince me either way.

The main point of using imports is that you get modularization.  Some of the advantages of that are:
  • Names (i.e. variables, functions, classes, etc.)  that you define in one file are distinct from names that you define in another file (including library files), unless they are exported by that module and imported in your file. This means that you can't accidentally redefine or re-assign something that another file defines.
  • The explicit exporting and importing enables tools like IDEs and compilers to provide better completions, refactorings, error discovery, optimizations, etc.
Here's a fun intro to JavaScript modules if you want a more complete explanation.

If your app remains small and simple, it's fine to just use script tags, but as apps get larger the advantages of modularization start becoming more useful and important.

Hope this helps.

-Mark

Max Stephen Russell

unread,
Jan 9, 2025, 3:38:19 PMJan 9
to Blockly
Here's my main.js file:

// Super Simple Test, Testing import
import * as Blockly from 'blockly/core';
import * as libraryBlocks from 'blockly/blocks';
import {javascriptGenerator} from 'blockly/javascript';
import * as En from 'blockly/msg/en';

Blockly.setLocale(En);

const testToolbox = {
    'kind': 'flyoutToolbox',
    'contents': [
      {
        'kind': 'block',
        'type': 'controls_repeat_ext',
        'inputs': {
          'TIMES': {
            'shadow': {
              'type': 'math_number',
              'fields': {
                'NUM': 13
              }
            }
          }
        }
      }
    ]
  };

  Blockly.inject('blocklyTestDiv', {
    toolbox: testToolbox,
    scrollbars: false,
    horizontalLayout: false,
    toolboxPosition: "begin",
  });

Here my index.html:

<!doctype html>
<html>
    <head>
        <meta charset="utf-8" />
        <title>Testing import</title>
    </head>
    <body>
        <h1>Hello Testing</h1>
     
      <div class="blockly-editor">
        <div id="blocklyTestDiv" style="height: 480px; width: 400px"></div>
      </div>
        <!-- These tags work with no problem:
          <script src="https://unpkg.com/blockly/blockly_compressed.js"></script>
          <script src="https://unpkg.com/blockly/blocks_compressed.js"></script>
          <script src="https://unpkg.com/blockly/javascript_compressed.js"></script>
          <script src="https://unpkg.com/blockly/msg/en.js"></script>
          <script src="./main.js"></script>
        -->
    </body>
</html>
In VS Code, Debugger says:

C:\Program Files\nodejs\node.exe .\rtl-website\main.js
Process exited with code 1
(node:105756) Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension.
(Use `node --trace-warnings ...` to show where the warning was created)
Uncaught SyntaxError C:\Users\maxsr\Dropbox\VSC Projects\rtl-website\main.js:2

import * as Blockly from 'blockly/core';
^^^^^^

SyntaxError: Cannot use import statement outside a module
    at wrapSafe (<node_internals>/internal/modules/cjs/loader:1378:20)
    at Module._compile (<node_internals>/internal/modules/cjs/loader:1428:41)
    at Module._extensions..js (<node_internals>/internal/modules/cjs/loader:1548:10)
    at Module.load (<node_internals>/internal/modules/cjs/loader:1288:32)
    at Module._load (<node_internals>/internal/modules/cjs/loader:1104:12)
    at executeUserEntryPoint (<node_internals>/internal/modules/run_main:174:12)
    at <anonymous> (<node_internals>/internal/main/run_main_module:28:49)

And in the terminal, npx webpack --mode=development gives me:

PS C:\Users\maxsr\dropbox\VSC Projects\rtl-website> npx webpack --mode=development
asset bundle.js 1.63 KiB [compared for emit] (name: main)
./main.js 677 bytes [built] [code generated] [1 error]


ERROR in ./main.js 2:0
Module parse failed: 'import' and 'export' may appear only with 'sourceType: module' (2:0)
File was processed with these loaders:
 * ./node_modules/babel-loader/lib/index.js
You may need an additional loader to handle the result of these loaders.
| // Super Simple Test, Testing import
> import * as Blockly from 'blockly/core';
| import * as libraryBlocks from 'blockly/blocks';
| import { javascriptGenerator } from 'blockly/javascript';

webpack 5.97.1 compiled with 1 error in 2312 ms

Mark Friedman

unread,
Jan 9, 2025, 7:29:11 PMJan 9
to blo...@googlegroups.com
Steve,

  It looks like you are in a no man's land between vanilla web apps using script tags, no packages, no bundler, etc., and full blown modern/complex web apps using imports, npm, webpack, etc.  As one issue, I'll just point out that you still need to run your web apps in a browser - using node to run them won't work.  Node is primarily for running servers and other JavaScript apps that don't run in browsers.  

  There are some other issues with the code you've posted but, rather than detail those, I would suggest taking a step back, because the path out of your no man's land is littered with pitfalls.  What I would suggest instead is you use Blockly's recommended starter application, which you can create using their create-package script (described here).  That will give you a minimal working Blockly-based module-friendly, web app which you can then modify to fit your specific needs.  It also generates all the appropriate tooling for npm, webpack, babel, etc. as well as pre-built commands (in package.json) which you can use to run development versions of your web app and to build your web app for distribution.  The generated README.md file explains this all in some more detail.

-Mark


Max Stephen Russell

unread,
Jan 9, 2025, 7:57:10 PMJan 9
to blo...@googlegroups.com
Mark,

The Node error info was included by me because it seemed to resemble the debugger. Whether or not it was useful, I could not tell. This is a rough neighborhood. I carefully installed the various components according to certain directions, but I’ll do some scrubbing and take your advice and run with the starter app. I had read about it and considered it, but I didn’t realize there was as much to it as I now see there is. This approach will also keep me inside a legitimate environment when I post in future days, and make life easier on you guys.

Thank you, and thank you to Christopher, VERY MUCH for all the help.

-Steve

Max Stephen Russell

unread,
Jan 9, 2025, 10:16:21 PMJan 9
to Blockly
Hi Mark,

What am I to make of these warnings after creating the starter application which you recommend?

PS C:\Users\maxsr\Dropbox\VSC Projects> npx @blockly/create-package app starter
Creating a new Blockly application called starter in C:\Users\maxsr\Dropbox\VSC Projects\starter
Installing packages. This might take a couple of minutes.
npm warn deprecated infl...@1.0.6: This module is not supported, and leaks memory. Do not use it. Check out lru-cache if you want a good and tested way to coalesce async requests by a key value, which is much more comprehensive and powerful.
npm warn deprecated rim...@3.0.2: Rimraf versions prior to v4 are no longer supported
npm warn deprecated gl...@7.2.3: Glob versions prior to v9 are no longer supported

Thanks.

-Steve

Christopher Allen

unread,
Jan 10, 2025, 6:55:30 AMJan 10
to blo...@googlegroups.com
Hi Max,

As Mark points out, the create-package script we provide is probably the easiest way to get set up for building a Blockly app, and we recommend that as the best way to get started with Blockly if you want to use ES modules.

Beyond that, most of your questions in this thread are more about JS ecosystem topics (build tooling, dependency managment etc.) than about Blockly itself, and unfortunately the JS ecosystem is so insanely complicated that it's probably not possible for us to answer all the questions you might have, even if we didn't have anything else to do all day.  :-(  Stack Overflow and similar sites are probably going to get you more information on these topics more quickly than we can.

That said, however, I happen to know the answers to a few of the questions you asked:

I'm getting an error that seems to have stricken many a programmer, with many fixes suggested and none of which has helped me.

ERROR in ./main.js 2:0
Module parse failed: 'import' and 'export' may appear only with 'sourceType: module' (2:0)

This is a simple problem: that your build system, in particular…
 
File was processed with these loaders:
 * ./node_modules/babel-loader/lib/index.js

… babel-loader (which I assume is related to Babel but which I am otherwise unfamiliar with), thinks your main.js is a "classic script", when you want it to be treated as a "module script".  This distinction that was introduced (along with the whole ES Module system) in ES6.  Here is a reasonably good explanation of the differences between several different kinds of JS scripts.

You need to tell your build system that you want your file to be treated as a module, not as a script.  How to do that depends on your tooling but the two most common fixes, that work in most cases, are:
  • add type: module to your package.json file, which which asks that all .js files in that directory and any subdirectories be treated as modules, or
  • rename files that contain modules from .js to .mjs.

What am I to make of these warnings after creating the starter application which you recommend?

PS C:\Users\maxsr\Dropbox\VSC Projects> npx @blockly/create-package app starter
Creating a new Blockly application called starter in C:\Users\maxsr\Dropbox\VSC Projects\starter
Installing packages. This might take a couple of minutes.
npm warn deprecated infl...@1.0.6: This module is not supported, and leaks memory. Do not use it. Check out lru-cache if you want a good and tested way to coalesce async requests by a key value, which is much more comprehensive and powerful.
npm warn deprecated rim...@3.0.2: Rimraf versions prior to v4 are no longer supported
npm warn deprecated gl...@7.2.3: Glob versions prior to v9 are no longer supported

These warnings can be safely ignored: inflight, rimraf and glob are dev dependencies (in fact, dev subdependencies) used by webpack to build your app, and do not become part of your app, so their being out of date should not have any impact on e.g., on the security of your bundled app.

We should probably update the versions used by our create-package script, but this is alas not a priority.  In principle you can update your own project by using npm, in the usual way; unfortunately in practice it can be fraught.


Good luck,

Christopher

Message has been deleted
Message has been deleted
Message has been deleted

Max Stephen Russell

unread,
Jan 14, 2025, 10:32:51 PMJan 14
to Blockly
Mark,

When you say "Also note that if you have other JavaScript files that access Blockly objects/APIs you'll need to put imports in those files as well," what would that mean as, using the starter app, I borrow a few files from the custom toolbox codelab? What import statements would I insert in these files? Also I know I won't use the codelab's script tags, but I don't yet understand their equivalent:

    <script src="custom_category.js"></script>
    <script src="toolbox_label.js"></script>

Possibly this situation does not relate directly to your comment.  I can't tell until I cross this bridge for the first time. Then I'll have more wind at my back!

Thank you.

Steve

Max Stephen Russell

unread,
Jan 14, 2025, 10:45:04 PMJan 14
to Blockly
For example, what import(s) would be needed for this custom_category.js borrowed from the codelab?:

/**
 * @license
 * Copyright 2020 Google LLC
 * SPDX-License-Identifier: Apache-2.0
 */

/**
 * @fileoverview The toolbox category built during the custom toolbox codelab, in es6.
 * @author aschmiedt@google.com (Abby Schmiedt)
 */

class CustomCategory extends Blockly.ToolboxCategory {
  /**
   * Constructor for a custom category.
   * @override
   */
  constructor(categoryDef, toolbox, opt_parent) {
    super(categoryDef, toolbox, opt_parent);
  }

  /**
   * Adds the colour to the toolbox.
   * This is called on category creation and whenever the theme changes.
   * @override
   */
  addColourBorder_(colour) {
    this.rowDiv_.style.backgroundColor = colour;
  }

  /**
   * Sets the style for the category when it is selected or deselected.
   * @param {boolean} isSelected True if the category has been selected,
   *     false otherwise.
   * @override
   */
  setSelected(isSelected) {
    // We do not store the label span on the category, so use getElementsByClassName.
    const labelDom = this.rowDiv_.getElementsByClassName('blocklyTreeLabel')[0];
    if (isSelected) {
      // Change the background color of the div to white.
      this.rowDiv_.style.backgroundColor = 'white';
      // Set the colour of the text to the colour of the category.
      labelDom.style.color = this.colour_;
      this.iconDom_.style.color = this.colour_;
    } else {
      // Set the background back to the original colour.
      this.rowDiv_.style.backgroundColor = this.colour_;
      // Set the text back to white.
      labelDom.style.color = 'white';
      this.iconDom_.style.color = 'white';
    }
    // This is used for accessibility purposes.
    Blockly.utils.aria.setState(
      /** @type {!Element} */ (this.htmlDiv_),
      Blockly.utils.aria.State.SELECTED,
      isSelected,
    );
  }

  /**
   * Creates the dom used for the icon.
   * @returns {HTMLElement} The element for the icon.
   * @override
   */
  createIconDom_() {
    const iconImg = document.createElement('img');
    iconImg.src = './logo_only.svg';
    iconImg.alt = 'Blockly Logo';
    iconImg.width = '25';
    iconImg.height = '25';
    return iconImg;
  }
}

Blockly.registry.register(
  Blockly.registry.Type.TOOLBOX_ITEM,
  Blockly.ToolboxCategory.registrationName,
  CustomCategory,
  true,
);


Max Stephen Russell

unread,
Jan 15, 2025, 10:47:14 AMJan 15
to Blockly
OK, I see that this is all a matter of export and import. But since I chose to begin my adventure with the Typescript version of the starter app, it is adding unhelpful complexity to the learning curve. I will start over with the "regular" version and come back to export/import questions, if I still have them. Thanks.

Steve

Mark Friedman

unread,
Jan 15, 2025, 5:31:31 PMJan 15
to blo...@googlegroups.com
This does relate to my comment.  Unfortunately (for this situation), the custom toolbox codelab code uses script tags.  If you wanted to use those files in a project that uses import statements, you would use something like:

import './custom_category.js';
import './toolbox_label.js';

Of course, it's a little more complicated than that because you can't simply put those import statements at the top-level of an HTML file.  They need to go inside a JavaScript module file.  In your case, where you're using the Blockly starter app, the place to put those import statements would be the index.js file, somewhere after the import statement for Blockly.

-Mark


Mark Friedman

unread,
Jan 15, 2025, 5:33:32 PMJan 15
to blo...@googlegroups.com
Indeed, adding learning TypeScript to your learning curve is probably unwise in the beginning ;-). This is especially so, given that all the Blockly example code is provided as plain JavaScript.

-Mark


Max Stephen Russell

unread,
Jan 15, 2025, 6:50:16 PMJan 15
to Blockly
Thanks again, Mark. I used to work with C++ header files all the time, so I should be able to break through this confusion without too much more struggle. I wonder if I could post the relevant files here and ask what is the reason the app is now breaking, and what I need to do, as I move these two files -- custom_category.js and toolbox_label.js -- into a modular setting. THANK YOU! -Steve


-- index.js --

/**
 * @license
 * Copyright 2023 Google LLC
 * SPDX-License-Identifier: Apache-2.0
 */

import * as Blockly from 'blockly';
import {blocks} from './blocks/text';
import {forBlock} from './generators/javascript';
import {javascriptGenerator} from 'blockly/javascript';
import {save, load} from './serialization';
import {toolbox} from './toolbox';
import './index.css';
// category customizations from custom-toolbox-codelab;
// one or both of these two scripts is breaking the app:
import './custom_category.js';
import './toolbox_label.js';
import './toolbox_style.css'

// Register the blocks and generator with Blockly
Blockly.common.defineBlocks(blocks);
Object.assign(javascriptGenerator.forBlock, forBlock);

// Set up UI elements and inject Blockly
const codeDiv = document.getElementById('generatedCode').firstChild;
const outputDiv = document.getElementById('output');
const blocklyDiv = document.getElementById('blocklyDiv');
const ws = Blockly.inject(blocklyDiv, {toolbox});

// This function resets the code and output divs, shows the
// generated code from the workspace, and evals the code.
// In a real application, you probably shouldn't use `eval`.
const runCode = () => {
  const code = javascriptGenerator.workspaceToCode(ws);
  codeDiv.innerText = code;

  outputDiv.innerHTML = '';

  eval(code);
};

// Load the initial state from storage and run the code.
load(ws);
runCode();

// Every time the workspace changes state, save the changes to storage.
ws.addChangeListener((e) => {
  // UI events are things like scrolling, zooming, etc.
  // No need to save after one of these.
  if (e.isUiEvent) return;
  // REMOVE THIS ALERT!
  alert("")
  save(ws);
});

// Whenever the workspace changes meaningfully, run the code again.
ws.addChangeListener((e) => {
  // Don't run the code when the workspace finishes loading; we're
  // already running it once when the application starts.
  // Don't run the code during drags; we might have invalid state.
  if (
    e.isUiEvent ||
    e.type == Blockly.Events.FINISHED_LOADING ||
    ws.isDragging()
  ) {
    return;
  }
  runCode();
});


-- custom_category.js --

/**
 * @license
 * Copyright 2020 Google LLC
 * SPDX-License-Identifier: Apache-2.0
 */

/**
 * @fileoverview The toolbox category built during the custom toolbox codelab, in es6.
 * @author aschmiedt@google.com (Abby Schmiedt)
 */

export default class CustomCategory extends Blockly.ToolboxCategory {
 /* createIconDom_() {
    const iconImg = document.createElement('img');
    iconImg.src = './logo_only.svg';
    iconImg.alt = 'Blockly Logo';
    iconImg.width = '25';
    iconImg.height = '25';
    return iconImg;
  } */
}

Blockly.registry.register(
  Blockly.registry.Type.TOOLBOX_ITEM,
  Blockly.ToolboxCategory.registrationName,
  CustomCategory,
  true,
);

-- custom_category.js --

/**
 * @license
 * Copyright 2020 Google LLC
 * SPDX-License-Identifier: Apache-2.0
 */

/**
 * @fileoverview The toolbox label built during the custom toolbox codelab, in es6.
 * @author aschmiedt@google.com (Abby Schmiedt)
 */

export default class ToolboxLabel extends Blockly.ToolboxItem {
  /**
   * Constructor for a label in the toolbox.
   * @param {!Blockly.utils.toolbox.ToolboxItemInfo} toolboxItemDef The toolbox
   *    item definition. This comes directly from the toolbox definition.
   * @param {!Blockly.IToolbox} parentToolbox The toolbox that holds this
   *    toolbox item.
   * @override
   */
  constructor(toolboxItemDef, parentToolbox) {
    super(toolboxItemDef, parentToolbox);
    /**
     * The button element.
     * @type {?HTMLLabelElement}
     */
    this.label = null;
  }

  /**
   * Init method for the label.
   * @override
   */
  init() {
    // Create the label.
    this.label = document.createElement('label');
    // Set the name.
    this.label.textContent = this.toolboxItemDef_['name'];
    // Set the color.
    this.label.style.color = this.toolboxItemDef_['colour'];
    // Any attributes that begin with css- will get added to a cssconfig.
    const cssConfig = this.toolboxItemDef_['cssconfig'];
    // Add the class.
    if (cssConfig) {
      this.label.classList.add(cssConfig['label']);
    }
  }

  /**
   * Gets the div for the toolbox item.
   * @returns {HTMLLabelElement} The label element.
   * @override
   */
  getDiv() {
    return this.label;
  }
}

Blockly.registry.register(
  Blockly.registry.Type.TOOLBOX_ITEM,
  'toolboxlabel',
  ToolboxLabel,
);

Mark Friedman

unread,
Jan 15, 2025, 8:03:23 PMJan 15
to blo...@googlegroups.com
Sorry, Steve.  I meant to also mention in my reply that you need to add an import for Blockly in custom_category.js (and in toolbox_label.js) because in the ES6 module world you can't depend on global variables (e.g. Blockly) as in the script tag world. You need to specify your dependencies in each file that uses them. So try adding the following in each of those two files:

import * as Blockly from 'blockly';

-Mark


Max Stephen Russell

unread,
Jan 15, 2025, 8:20:15 PMJan 15
to Blockly
That did it! Thanks a million, Mark! You know, I was looking at those files and wondering what kind of import they might use but couldn't see the obvious. I still don't entirely grasp the interactions of the customization, registry, etc., between the files, but now I'm in the game and will engage at all these different points.

Make that a billion!

Steve

Mark Friedman

unread,
Jan 16, 2025, 1:14:42 PMJan 16
to blo...@googlegroups.com
One way to think about it, Steve, is that, for the most part, in the ES6 Module world all the variables, functions, and classes that you reference in your files should either be defined in that file, be standard built-in JavaScript, or be explicitly imported.

-Mark


Reply all
Reply to author
Forward
0 new messages