Split Handlebars into multiple packages

[nknapp]

@wycats and me discussed this a couple of weeks ago:

The ember project is currently using the Handlebars parse to generate an AST, but it is using an older version (I believe version 3). Version 4 has some features that aren't needed by ember and won't be needed.

By extracting the parser from the main project, we would reach several goals.

• Lower footprint for tooling projects that actually only need the parser but have to include the whole runtime at the moment.
• A single source of truth for the Handlebars-language (used by ember and Handlebars). We would probably integrate some of the newer Ember features like components as well.
• There would be several flavours of the language (core, "handlebars.js") where "core" would
  not have some of the features (like inline-partials). Those features are still to be defined (we need a spec).
• It would give us a chance to create a clean and well-documened API for the parser and build on new technologies (I find jison very hard to work with, especially since I have found no IDE integrations for .yy and .l files.

What I was thinking about now is: Extract not only the parser, but only the precompiler into its own package.

We could have the following npm-packages:

• @handlebars/parser - to include the parser
• @handlebars/compiler - to include the javascript-compiler
• @handlebars/runtime - to include the runtime
• handlebars - the current package, which uses them all (and binds them). The main goal of this
  package should be to maintain backwards-compatibility, but use the extracted packages to
  avoid duplicate code.

I am not sure if it is a good idea to extract compiler and runtime into separate packages though.
The source of new packages could be moved to the handlebars-lang org on github.

Any opinions on this?

How do we get there?

Starting with the parser, I was thinking about setting up a new repo in the handlebars-lang-org. I would like to start fresh, with modern tools (current webpack and babel versions, prettier for formatting, eslint only for linting, possibly jest or "mocha/chai", possibly semantic-release.

The we should look at the current tests and see if we cannot transform them into a language independent form like

template: "{{test}}"
ast:
  type: Program
  body:
    - type: MustacheStatement
      path:
        type: PathExpression
        data: false
        depth: 0
        parts:
          - test
        original: test
        loc:
          start:
            line: 1
            column: 2
          end:
            line: 1
            column: 6
      params: []
      escaped: true
      strip:
        open: false
        close: false
      loc:
        start:
          line: 1
          column: 0
        end:
          line: 1
          column: 8
  strip: {}
  loc:
    start:
      line: 1
      column: 0
    end:
      line: 1
      column: 8

This would other people allow to build a compatible parser as well (in other languages)

[kanongil]

Any chance that this can get revisited? Something like this could help avoid security warnings (#1661) for projects that don't use the cli.

[nknapp]

This is a long term project. Not something that will be finished in the next months, at least not if I am the only one working on it.

[jaylinski]

The parser was split into a separate package in #1713.