this.err currently receives more info via errParams than the baseline error reporter needs.
this was for the upcoming tolerant mode, but tolerant subsystem is going to get implemented in a totally new way so sending those extra params will no longer be necessary.

While working on the 0.6 version I noticed what I think is a typo at src/[email protected]#366:

this.err('switch.has.no.opening.curly', startc, stratLoc));

I suppose that the third argument should be startLoc instead of stratLoc.

Hi
Before we begin, let's go over a few definitions.

A "potpat" is a node that has the potential of becoming an assignment- and/or a binding-pattern -- these nodes areMemberExpression, AssignmentExpression, ObjectExpression, Property (almost), Identifier, and ArrayExpression; please not though, that while [a] is a potpat, -[a] is not, because it can't appear at left of an assignment.

A "parpos" node is a node that can be an arrow parameter. in ([a, { b = [[e], l] = 12}]), a and b are parpos nodes; in -([a]), there is no parpos, because the - behind the ( will make it impossible for the paren to serve as the parameter list of an arrow function.

A "tricky" situation (as I have no other name for it) is, broadly, a situation in which the node is probably an error, but its erroneousness can not be ascertained.

consider the following cases:

"use strict";
[ eval, // not yet an error, but as a part of a "potpat", it might well turn into an error.
  arguments = 12 // an error, but may not be the first one, so it will not immediately throw
]
; // <-- now we are sure about `arguments = 12` being an actual error

[ eval,
  arguments = 12
]
= // <-- now we are sure about `eval` being an actual error; `arguments = 12` is no longer the first error
12;

[{ a= b }, // possible error #1
 [ arguments ] = 12, // possible error #2
]
= // raise #2
12;

(
   12, // surprisingly, it is not considered tricky, because it is not potpat
   [(a)], // possible error #1 -- if it is a parpos, `(a)` will be an invalid parameter
   e * 12, // this is not tricky either
   {a=b} // possible error #2 -- if it isn't a parpos, it will be an unsatisfied assignment
)
; // raise #2

(
    [(a)], // possible error #1
   12,
    e * 12, 
    {a=b} // possible error #2
) => /* <-- raise #1 */ 12
// please note that, in the case above, if `12` had come first, it'd have been the error finally raised --
// "possible" errors, like their name suggests, are raised if only no error has happened before them.

function* l() {
   "use strict";
   (a=yield, // possible error #1-- it is a parpos node, and if it turns out to be an actual param, 
                 // it is not allowed to contain a yield expression
    arguments=12 // possible error #2
    )
    ; // raise #2

    (a=yield, // possible error #1
     arguments = 12 // possible error #2
    ) => /* <-- raise #1 */ 'l';
}  

There is also an extreme case; considering we are in a generator, what should the error for the following code be?

(yield)=>12

rather simple -- it should be "yield can not be an array parameter when in a generator".

But what about this one (again considering we are inside a generator)?

(yield = 12) => 12

This one should raise the same error as above; but this means we should actually postpone an outright error -- a syntactic one (rather than a semantic one, which would've been easier to deal with) --until the ) is reached.
But of course things are not that hard, and the "syntactical" error we are worrying about is only contextually considered a syntax error, since in a non-generator, non-strict context, yield = 12 is indeed allowed.

The case is dismissed though -- yield is an actual keyword inside a generator, so (yield)=>12 and (yield=12)=>12 will be just as erroneous as (while)=>12 and (while=12)=>12.

That makes for the foreword.

Jazzle is currently using multiple variables (firstYS, parenYS, firstElemWithYS, firstParen, firstUnassignable, firstNonTailRest, firstEA, firstEAContainer 💦) to track all the issue above, and while it does a decent job tracking all these tricky cases, it still looks like to be doing it in a more complicated fashion than it actually should.
I believe a more straightforward (and more lightweight) approach has got to be found.

As an analogy, there are two ways of counting sheep.

One is to count the hooves, and divide the result by 4; this approach needs top-notch counting skills.
The other is to count the heads; even I can do it.

But looks like jazzle in its current state is counting the hooves.

aside from cleaning them up, early errors are getting neglected in the meantime (duplicate exports, etc.)
also check whether they are indeed appearing as module-level constructs.

@icefapper

1. Import and Export is broken. Does not handle early errors. E.g

   var a, b; export default a; export { b as default };
export { a, b as c }
export default 1; export default 2;
export { a as default }
export { a }

All this fails. See also #12

2. Async parses for ES6
3. Exponent parses for ES6
4. ESTree violation. Author call it "extra information".

And does not handle

({a({e: a.b}){}})
(function* ({e: a.b}) {})
(function ({e: a.b}) {})

And most of the todos in the code haven't been fixed for months

I noticed that the build system has created a lot of boilerplate and indirection in the bundle. It's effectively a concatenation script, but with some special semantics that are plainly very unidiomatic, and introduce numerous otherwise-unnecessary closures at load time.

To give an example, here's a snippet from your src/[email protected]

this.err = function(errorType, errParams) {
  errParams = this.normalize(errParams);
  return this.errorListener.onErr(errorType, errParams);
};

You could just as easily do this instead:

Parser.prototype.err = function(errorType, errParams) {
  errParams = this.normalize(errParams);
  return this.errorListener.onErr(errorType, errParams);
};

Doing this would let you just make your build script a glorified cat program, that just happens to wrap everything in an IIFE.

This would be much simpler to write and maintain, even if you decided to keep the naming convention. In fact, UglifyJS2 already does similar.

that is, the exported parse function and the Parser constructor; the options ought to be esprima/acorn compatible, making jazzle a transparent drop-in.

jazzle needs its own website, among other things, in order to get recognized.
jazzle.org has to go online as soon as possible.

@icefapper Hi! I tried this module. Awsome work!

But is there any way I can turn of this misleading location stuff ? In Acorn and Esprima that is off by default, and can be activated through options.

And I also noticed that the location is not compatible with either Acorn or Esprima. Is this something that will be fixed?

@icefapper

• object spread (Acorn have had this for a year at least)
• dynamic import
• new template features
• JSX (a must to have)

it has got to be sent to every parseExpr and parseNonSeqExpr that is not a sub-expr -- top-level exprs in other words.
otherwise there are going to be inconsistencies while parsing them, especially while tracking the so-called "tricky" cases.

@icefapper I noticed the effort you put into splitting the codebase into smaller components but unfortunately, in my opinion, it's not completely on the mark yet.

For now you should only think about node's environment and focus on making the best use of its module system. A practical example of this would be what I've done in the parser folder where:

1. Prototype functions are defined one-per-file in parser/parse and parser/util.
2. Shorthands that are meant to be used by only a function (like #asArrowFuncArgList and #asArrowFuncArg being called only by Parser#parseArrow) are now bound to that function module's scope.
3. The constructor is a function defined in parser/constructor.js.
4. The parser's entry point is parser/index.js which automatically binds the prototype to its constructor.

Pros & Cons

Pros

• Hierarchical organization of modules
• No global space pollution (like with the _class)
• Better scope management thanks to modules (you expose only what you need)
• Natively supported by node (no need for compilation/transpilation of any sort)

Cons

• The browser version requires to be generated via browserify

Additional notes

While the use of browserify might look a bit restrictive, it is very advantageous instead. Why? It can generate UMD builds!. This way jsRube would work as intended independently of how it is loaded in the browser (be it a src tag, an AMD module loader a CommonJS module loader or whatever).

By the way, if you want to discuss privately, I'm always avaiable at [email protected].

almost all other submodules have been rewritten. this one requires something along those lines too -- things CONTEXT_UNASSIGNABLE_CONTAINER are still in there even though they've been swept out for quite some time actually.

Hello
as it currently stands, this results in a 'unexpected =`; i know it is being rather too pedantic, and that it might require extra work to achieve it, but I believe it should be 'invalid parameter name: yield' instead.

Hello
Just wantd to say jsRube's AST are slightly different from those of esprima; for example, while jsRube keeps nodes' start and end locations ('loc') in 'start' and 'end', respectively, esprima keeps them in 'ranges'. The code at the beginning of the function 'compare' in module './util.js' is actually the 'adjuster' code. Thanks a lot reading this far.