Jeff Morrison

There's no technical reason we couldn't support . The only reason we haven't is because we support comments in {} expressions (which was technically simpler and covered more flexibility). My...

I also don't think is really that much better than {/\* */} (It's the same number of chars even)

Oh...this issue is super old...

@camronjroe: Having a parser flag to turn this on/off would be a not so great idea. It would mean react component interop (meaning like sharing react components) wouldn't just work...

@syranide: I won't die on a hill against this, and I agree it's /maybe/ not common to have // or /*, but it's the times where it does that would...

Although I am a reasonable human and prefer to know as soon as possible when I have a mistake, I don't think throwing on duplicate property would be very consistent...

FYI: Just fixed (1) in https://github.com/wycats/javascript-decorators/pull/34

Update: We've spent some time circling our options and here's where we're at: There are two perspectives we have to consider when approaching this problem: Library-definition authors (who would prefer...

@dckc: There is `flow ast` which will emit a JSON ESTree\* AST given some file content. \* Two minor caveats to calling the output "ESTree": 1) Flow obviously has syntax...

@sebmck: Do you think the codegen utils in Babel that work with the Babylon AST would work for @dckc? If so, do you have any pointers to them? I was...