bump!
0.9.0 maybe?

Personally, I think the core components should be split out into another library (ast-types-base for sake of argument).

I like the syntax, but I think you should pass actual modules (or a custom function) instead of strings. The problem with strings would be accurately resolving them (especially if you do split into a separate module):

var types = require('ast-types-base')(
  require('ast-types/def/core'),
  require('./myCustomDefs'),
  function(types) {
   types.def('MyType')
     //...
  }
);

I do like the fork option discussed, and that seems appropriate for ast-types, but not ast-types-base as I'm proposing. Perhaps strings would make sense there for specifying some of the built in stuff.

This would be the equivalent, less verbose version of above:

require('ast-types').fork(
  'core',
  require('./myCustomDefs'),
  function(types) {
   types.def('MyType')
     //...
  }
);

One problem with the fork method as currently being discussed would be with browserify builds. Browserify will pick up and package everything in def/*, even if you aren't using any of it and creating an entirely custom AST. Splitting into a separate module eliminates that problem for people implementing ground up AST definitions, and the top syntax above could still be used by those targeting browserify to ensure only what they want from def/* will be packaged in the bundle.

Proposal: Make the project generalized #57

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions