[BREAKING] Glimmer.js 2.0

[pzuraq]

This PR refactors the codebase and public APIs of Glimmer.js significantly in preparation for Glimmer.js v2.0. It includes the following changes:

Removals

• @glimmer/app-compiler
• @glimmer/application-test-helpers
• @glimmer/application
• @glimmer/compiler-delegates
• @glimmer/test-utils

Additions

• New package: @glimmer/core:

  • renderComponent - the new primary public API for starting a Glimmer application. You pass a component definition to it as the first parameter, and an element or options hash as the second, and it renders this component.

    renderComponent(MyComponent, { element: document.querySelector('#app') });

  • setComponentTemplate and createTemplate - New base API for defining a component's template, including imports:

    setComponentTemplate(
      MyComponent,
      createTemplate(
        { MyOtherComponent },
        '<MyOtherComponent/>'
      )
    );

  • A component manager that matches Ember's custom component manager API

  • A basic modifier manager, which still needs to be updated to match Ember's (in a followup PR)

• New package: @glimmer/modifier:

  • An importable {{on}} modifier that matches Ember
  • An @action decorator which matches the binding semantics of Ember's (but not the other behaviors)

• New package: @glimmer/helper:

  • A basic API for writing simple functional helpers. This will likely be updated before the final v2.0 release.

• New package: @glimmer/babel-plugin-glimmer-env:

  • Provides a super simple wrapper around babel-plugin-debug-macros to minimize setup cost, and provide debug stripping for @glimmer/env. This is critical now that glimmer-vm ships with the DEBUG flag intact.

• New package: @glimmer/babel-plugin-strict-template-precompile

  • Provides the compile-time transform for createTemplate()

Updates

• @glimmer/component

  • Removed didInsertElement, bounds, and other unnecessary APIs from GlimmerComponent
  • Minor tweaks to types to make them more accurate: GlimmerComponent<T = object> -> GlimmerComponent<Args extends {} = {}>

• @glimmer/blueprint

  • Updated the output of the blueprint to remove ember-cli and use webpack instead. Provides a much more minimal setup, that is less opinionated. Still supports TS out of the box (but defaults to JS), and contains some basic configuration.

• Overall

  • Removes the broccoli build chain in favor of a webpack build for local development and tests, and pure TS build for publishing.
  • Removes TSLint, adds ESLint with Typescript presets and configuration
  • Adds Lerna for publishing management
  • Adds an example-apps directory, with the future intention being to add more complex examples including the Glimmer playground.

Next Steps

• Update the Glimmer VM to the latest
• Sync ModifierManager with Ember's impl
• Add ExperimentalHostMeta
• Add ExperimentalHelperManager
• Add moar tests

[chadhietala]

Thanks for doing this @pzuraq! Some comments, nothing major though.

[lifeart]

One silly question, it it possible to return app instance in renderComponent promise resolution?

ref: glimmerjs/glimmer-experimental#45

[pzuraq]

@lifeart I've been thinking about that a bit, I think it would actually be good to return a public API of sorts. Specifically, I'd like the ability to destroy the instance so that manually managed instances can be cleaned up properly, but that could be expanded in the future.

I think we can do that as a separate PR though, either before v2 is released or sometime after. What use cases were you thinking of that you'd like to support?

[lifeart]

@pzuraq use cases:

• web components api integration (properties, attributes, destroying) support.

https://gist.github.com/lifeart/2c4666844a11b1e8536a32d6c776aacc

external access to rendered component instance to support attributeChangedCallback, connectedCallback, disconnectedCallback, adoptedCallback

• multiple glimmer applications in one page with single state management (including it's lifecyle) just like multiple Vue apps in one page, to have ability integrate glimmer with legacy systems step-by step.

If we have external data source or business logic, it will be great to have access to root component instance to invoke some methods or set properties to it without hacking.

and I was thinking about ability to make first render sync (not promise-based), to support sync web-components api

[chadhietala]

@pzuraq looks like the publishing script was removed. Any intention of bringing it back in this PR?

[pzuraq]

I believe we can just use lerna publish with this setup, as it builds the packages directly in the same directory rather than a new dist folder. I found this pretty convenient for local linking as well.

[rwjblue]

Why is this file here? Shouldn't be in a subdir?

[rwjblue]

Should depend on esm no?