Babel: Class extends does not work in babel 6

[KnisterPeter]

The following code does not compile with babel 6 but throws an error (which is not very informative):

class Expression {}

export class ArrayExpression extends Expression {
}   

~/source/ankara (master)$ ./node_modules/.bin/babel test.js 
Error: test.js: We don't know what to do with this node type. We were previously a Statement but we can't fit in here?
    at NodePath.insertAfter (/home/markusw/source/ankara/node_modules/babel-cli/node_modules/babel-core/node_modules/babel-traverse/lib/path/modification.js:181:13)
    at NodePath.replaceWithMultiple (/home/markusw/source/ankara/node_modules/babel-cli/node_modules/babel-core/node_modules/babel-traverse/lib/path/replacement.js:92:8)
    at handleClassWithSuper (/home/markusw/source/ankara/node_modules/babel-preset-stage-1/node_modules/babel-plugin-transform-class-constructor-call/lib/index.js:80:10)
    at PluginPass.Class (/home/markusw/source/ankara/node_modules/babel-preset-stage-1/node_modules/babel-plugin-transform-class-constructor-call/lib/index.js:101:11)
    at newFn (/home/markusw/source/ankara/node_modules/babel-cli/node_modules/babel-core/node_modules/babel-traverse/lib/visitors.js:233:27)
    at NodePath._call (/home/markusw/source/ankara/node_modules/babel-cli/node_modules/babel-core/node_modules/babel-traverse/lib/path/context.js:72:18)
    at NodePath.call (/home/markusw/source/ankara/node_modules/babel-cli/node_modules/babel-core/node_modules/babel-traverse/lib/path/context.js:44:17)
    at NodePath.visit (/home/markusw/source/ankara/node_modules/babel-cli/node_modules/babel-core/node_modules/babel-traverse/lib/path/context.js:102:12)
    at TraversalContext.visitQueue (/home/markusw/source/ankara/node_modules/babel-cli/node_modules/babel-core/node_modules/babel-traverse/lib/context.js:151:16)
    at TraversalContext.visitSingle (/home/markusw/source/ankara/node_modules/babel-cli/node_modules/babel-core/node_modules/babel-traverse/lib/context.js:111:19)

My .babel.rc contains the following:

{
  "presets": ["stage-1"],
  "plugins": ["transform-async-to-generator"]
}

The following snippet does work:

class Expression {}

export class ArrayExpression {
}   

[eelkeh]

You stil need the es2015 preset, like ["es2015", "stage-1"]

[alexfedoseev]

Exactly the same issue.

.babelrc

{
  "presets": ["es2015", "stage-0", "react"]
}

[jamiebuilds]

I'm able to get this working without issue by enabling the es2015 preset. See thejameskyle/__babel-bug-2700

But if you disable the es2015 preset you can see the error message above where the transform-class-constructor-call plugin is depending on the es2015 class transformer.

[jamiebuilds]

There's an additional issue if you are setting an extended class as the default export it errors:

export default class MyComponent extends React.Component {}

Error: index.js: We don't know what to do with this node type. We were previously a Statement but we can't fit in here?
    at NodePath.insertAfter (/Users/thejameskyle/Projects/Tests/__babel-bug-2700/node_modules/babel-traverse/lib/path/modification.js:181:13)
    at NodePath.replaceWithMultiple (/Users/thejameskyle/Projects/Tests/__babel-bug-2700/node_modules/babel-traverse/lib/path/replacement.js:92:8)
    at handleClassWithSuper (/Users/thejameskyle/Projects/Tests/__babel-bug-2700/node_modules/babel-plugin-transform-class-constructor-call/lib/index.js:80:10)
    at PluginPass.Class (/Users/thejameskyle/Projects/Tests/__babel-bug-2700/node_modules/babel-plugin-transform-class-constructor-call/lib/index.js:101:11)
    at newFn (/Users/thejameskyle/Projects/Tests/__babel-bug-2700/node_modules/babel-traverse/lib/visitors.js:233:27)
    at NodePath._call (/Users/thejameskyle/Projects/Tests/__babel-bug-2700/node_modules/babel-traverse/lib/path/context.js:72:18)
    at NodePath.call (/Users/thejameskyle/Projects/Tests/__babel-bug-2700/node_modules/babel-traverse/lib/path/context.js:44:17)
    at NodePath.visit (/Users/thejameskyle/Projects/Tests/__babel-bug-2700/node_modules/babel-traverse/lib/path/context.js:102:12)
    at TraversalContext.visitQueue (/Users/thejameskyle/Projects/Tests/__babel-bug-2700/node_modules/babel-traverse/lib/context.js:151:16)
    at TraversalContext.visitSingle (/Users/thejameskyle/Projects/Tests/__babel-bug-2700/node_modules/babel-traverse/lib/context.js:111:19)

[mlegenhausen]

It also seems that the order of the applied presets is important.

{
  "presets": ["stage-1", "es2015"]
}

Fixes the error when using class-properties but has the described bug that extends does not work anymore. When I switch to ["es2015", "stage-1"] then extends does work again but class-properties is broken.

I will try out to set all the plugins manually to fix this bug.

[dschissler]

When exporting a default annonymous class I get:

Property id of VariableDeclarator expected node to be of a type ["LVal"] but instead got null`

and when I give it a name it becomes:

We don't know what to do with this node type. We were previously a Statement but we can't fit in here?

[edit] I'm using es2015 and stage-0 in that order.

[riophae]

Same issue still exists with Babel 6.0.20.

[sebmck]

No it doesn't. Make sure all your dependencies are at the latest. Wipe your node_modules and reinstall.

[electerious]

… or use npm list and check if the current version is installed.

However, there seems to be another issue with export default throwing the following:

Property id of VariableDeclarator expected node to be of a type ["LVal"] but instead got null while parsing file: […]Main.js

See https://github.com/babel/babel/issues/2694

[feugenix]

I installed Babel 6.0.20. (after cleaning node_modules) and problem is gone! Many thanks.

[mattstyles]

This will break it though...

export default class Foo {
  constructor() {
    this.foo = 'foo'
  }
  static bar = 'bar'
}

./node_modules/.bin/babel --preset es2015 --plugin transform-class-properties class.js

It's the static prop, regular class props (even async ones with the async transformers) and all is happy. Doesn’t seem to like attaching the prop to Foo as it normally would (whacking the export on its own line still works around this one)

[CMTegner]

@mattstyles sounds a lot like #2722. Using static class props doesn't work for me, regardless of where I put the exports statement.

[mattstyles]

Using very latest versions ( cli 6.1.1 ), does this work for you:

class Foo {
  static bar = 'bar'
}
export default Foo

./node_modules/.bin/babel --preset es2015 --plugin transform-class-properties class.js

It's working here for me

var Foo = function Foo() {
  _classCallCheck(this, Foo);
};

Foo.bar = 'bar';
exports.default = Foo;

[CMTegner]

@mattstyles yep, you're correct. My version of babelify was using an outdated version of babel-core, which caused plugin/preset order to play into the final transpiled output. I can confirm that the placement of the export statement effects the static <class property> syntax.

Works:

class Foo {
    static bar = 'bar'
}

export default Foo

Does not work:

export default class Foo {
    static bar = 'bar'
}

Reason:

We don't know what to do with this node type. We were previously a Statement but we can't fit in here?

This is with [email protected], [email protected], and [email protected].

[mattstyles]

For what it worth, export or export default makes no difference

export class Foo {
  static bar: 'bar'
}

[heydenberk]

Regarding the issue that @mattstyles mentions above, I have posted a reduced test case in a gist in a related issue here: https://github.com/babel/babel/issues/2779#issuecomment-153453428

[84564221]

export default class MyClass {
  // field, constructor, and 
  // method declarations
}

The example from above follows the ECMAScript 2015 specification. You do not need to convert your assignment-expressions into class-declarations!

class MyClass {
  // field, constructor, and 
  // method declarations
}

export default MyClass;

[84564221]

15.2.3 Exports

Syntax

_ExportDeclaration_ :

export * _FromClause ;_
export _ExportClause FromClause ;_
export _ExportClause ;_
export _VariableStatement_
export _Declaration_
export default _HoistableDeclaration_
export default _ClassDeclaration_
export default [lookahead ∉ {function, class}] _AssignmentExpression ;_

[hzoo]

I hope we didn't imply anywhere that it's not a bug in babel - I think some people just want to use babel 6 and will use the workaround - but you should certainly use 5.8 if you don't want to change or don't want to go through waiting for the initial bugs to be fixed

[michaelahlers]

“Me, too.” I had been exporting anonymous classes as specified by 15.2.3 (which @askmatey cited), and I'm now getting the same error as mentioned by @dschissler with 6.1.

[EvHaus]

This is still an issue in v6.1.4. Can you please re-open the issue?

[sebmck]

Someone give me an actual reproduction that works on the latest version of Babel. I'm sick of getting these "this is broken" comments without actual code and options to use

[heydenberk]

I believe I posted a complete test case in a comment above: https://github.com/babel/babel/issues/2700#issuecomment-153454256

Here it is: https://gist.github.com/heydenberk/56b654e05b38c88ca472

[voodooattack]

Still occurs with this:

presets: ['es2015', 'stage-1', 'react']

export default function createComponent(options = {}) {
  return class DynamicComponent extends React.Component
  {
    static displayName = 'DynamicComponent';
  };
}

[elado]

Getting this too, but only with webpack. babel-loader version is ^6.1.0.

// webpack.config.js

var webpack = require('webpack')
var path = require('path')
var fs = require('fs')

module.exports = {
  entry: [
    './src/scripts/index.js',
  ],
  output: {
    path: path.join(__dirname, 'static'),
    filename: 'bundle.js'
  },
  devtool: 'source-map',
  module: {
    loaders: [
      {
        test: /\.jsx?$/,
        loader: 'babel?' + JSON.stringify({ plugins: ['transform-runtime'], presets: ['stage-0', 'es2015', 'react'] }),
        include: path.join(__dirname, 'src/scripts')
      }
    ]
  },
  resolve: {
    extensions: ['', '.js', '.jsx']
  }
}

// index.js

export default class A extends B {
}

// package.json versions

  "devDependencies": {
    "babel-core": "^6.1.4",
    "babel-loader": "^6.1.0",
    "babel-plugin-transform-runtime": "^6.1.4",
    "babel-preset-es2015": "^6.1.4",
    "babel-preset-react": "^6.1.4",
    "babel-preset-stage-0": "^6.1.2",
    "bootstrap-sass-loader": "^1.0.9",
    "webpack": "^1.12.4"
  }

[elado]

OK, isolated the issue, it's not specifically babel-loader but the presence of .babelrc in the project. Seems like babel-core applies plugins/presets twice.

Reproduce:

// .babelrc

{
  "plugins": ["transform-runtime"],
  "presets": ["es2015", "stage-0", "react"]
}

// a.js

export default class A extends B {
}

// console

$ babel a.js
// => success!

$ babel a.js --plugins=transform-runtime --presets=es2015,stage-0,react
// => SyntaxError: a.js: 'this' is not allowed before super() (This is an error on an internal node. Probably an internal error)

babel-loader sends the query too and babel reads from the rc file.

If I delete the babelrc file, it works with the flags/webpack.

cc @sebmck

[sebmck]

@elado That's issue #2942.

[elado]

@sebmck still happens with static props (currently reproducing with webpack)

export default class A extends B {
  static prop = 1
}

Error: We don't know what to do with this node type. We were previously a Statement but we can't fit in here?

[elado]

And... that was actually because of the order of my presets.
Used ['stage-0', 'es2015', 'react'], should've used ['es2015', 'stage-0', 'react']

I can confirm this is fixed. Thank you so much!

[mikestopcontinues]

With ['es2015', 'stage-0', 'react'], I get this new error, babel and all plugins up to date.

./scripts/site/SiteLoader.js
Module build failed: SyntaxError: /ui/node_modules/eslint-loader/index.js!/Users/msc/HuffPost/chronos/ui/scripts/site/SiteLoader.js: Decorators are not supported yet in 6.x pending proposal update.
  12 |   };
  13 | })
> 14 | export default class SiteLoader extends Component {
     |                ^

[ream88]

@elado comment worked for me.
Maybe this is out of the scope of this issue, but shouldn't the presets warn you if not loaded in the right order? Or at least we need documentation on it.

[mikestopcontinues]

Why should presets have order? Shouldn't it be the rules that specify the order they run in?