Current problems with the low-level API

[izelnakri]

Hi there,

I was first thinking of writing a long issue detailing the history on how I tried to extend @glimmerx/@glimmer to make it work like ember.js by just using node.js/typescript standards(without any babel addons, not even the babel typescript addon), however it would be too long so instead I'll summarize the issue here:

• Glimmer compiler is currently coupled with babel, cannot be used in node.js without a very custom, specific and "error-prone during customization" build process. In other words the current low-level API of glimmer is not low-level enough and implicitly assumes many things to be set up, that is not declared explicitly in the end-user code, has to be implicitly built/set up when developer wants to do his:

import { precompileTemplate, setComponentTemplate } from '@glimmer/core';
import { on } from '@glimmer/modifier';

setComponentTemplate(
  precompileTemplate(
    templateString, // NOTE: current babel transpiler throws a buggy exception when this is not an absolute template string(i.e instead its a variable that holds a string)
    {
      strictMode: true,
      scope: () => {
        return { on };
      },
    }
  ),
  MyComponent
);

I was very happy when I saw the new @glimmer package has the low-level api to declare scopes, and in practice thats all we should need for in-browser compilation or for precompilation really. Ideally setComponentTemplate should output the glimmer op-code or custom data structure for use in the mounting API(renderComponent).

However this is not how it works now, there is more implicit build step executions happening that makes the low-level api, not low-level enough yet and ties the developer experience to a custom build process that cannot be even reproduced easily in a stable fashion. Each release of these custom npm babel build packages in addition to their configuration in babel and webpack, introduces a potential for a buggy release/update. Only after we have a reliable standalone compiler that can be run in the cli or in the node.js environment(node.js, ts-node or deno) we can effectively experiment and build on top of glimmer.

Riot.js does this really well in their compiler tools: https://riot.js.org/compiler/#in-browser-compilation-with-inline-templates

They introduce both node.js API and cli, esbuild does the same. We should do the same, we can add our learnings to the option object/customization of the compiler function(scope, services, args, trackedComponentDefinition inside the options object or cli flags).

Current bug in the npm package/release @glimmer/core@v2.0.0-beta.16

The distributed @glimmer/core package.json points to:

  "main": "dist/commonjs/index.js",
  "module": "dist/modules/index.js",

node_modules/@glimmer/core/dist/commonjs/src/template.js#3 is exports.precompileTemplate = void 0;
node_modules/@glimmer/core/dist/modules/src/template.js#3 is export let precompileTemplate;;

In other words, @glimmer/core is currently unusable in node.js

[lifeart]

precompileTemplate import should be handled by @glimmer/babel-preset, adding it to babel config should solve unknown export issue

[lifeart]

also, found that arrow functions not working for helper manager