The class decorators are not correctly positioned in the AST.

The class decorators array is put before the Class Declaration element instead of being put as the decorators property’s value of the Class Declaration element.

Here is an example. Given the following JavaScript code:

import {MyDecorator} from './decorators.js';
@MyDecorator
class MyViewModel {
}

the output AST is:

[
  {
    type: 'ImportDeclaration',
    specifiers: [ [Object] ],
    source: {
      type: 'Literal',
      value: './decorators.js',
      start: 26,
      end: 43,
      range: [Array]
    },
    start: 0,
    end: 44,
    range: [ 0, 44 ]
  },
  [
    {
      type: 'Decorator',
      expression: [Object],
      start: 45,
      end: 57,
      range: [Array]
    }
  ],
  {
    type: 'ClassDeclaration',
    id: {
      type: 'Identifier',
      name: 'MyViewModel',
      start: 64,
      end: 75,
      range: [Array]
    },
    superClass: null,
    decorators: [],
    body: { type: 'ClassBody', body: [], start: 76, end: 79, range: [Array] },
    start: 58,
    end: 79,
    range: [ 58, 79 ]
  }
]

As you can see the ClassDeclaration.decorators property is an empty array. But just before the ClassDeclaration object there is an array of decorators.

Removing the lines

    case Token.Decorator:
      return parseDecorators(parser, context) as ESTree.Decorator[];

from the parseModuleItem() function seems to fix the problem.

[3cp]

Legacy decorator is very popular, has been used in many front-end frameworks. TypeScript’s decorator closely resembles legacy decorator. New decorator proposal is making noise for years, but I have not encountered any real usage.

Babel parser has moved from legacy to latest proposal, but provided two switches, one to turn on legacy decorator syntax, another only to turn on decoratorBeforeExport (as you can see, forcing decorator after export default is quite unpopular).

Since new decorator proposal is going nowhere and legacy decorator is still alive, I suggest we support decorator before and after export regardless. I don’t think we need a flag to turn decoratorBeforeExport on and off, because it only causes confusion to end users who are lost in this decorator spec mess.

If this sounds right, I can draft an implementation later next week.

[3cp]

I put the fix to a branch now.