That is not valid syntax. You can do

export { Post }

or even just

export var Post = Parse.Object.extend('Post')

or shorten the whole file to

export default Parse.Object.extend('TestObject')
export var Post = Parse.Object.extend('Post')

Your imports are also incorrect, you'll want to do

import TestObject, { Post } from '../store'

This is if you really want a single default export and a separate named export. You can also just make two named exports and have no default if you want, e.g.

export var TestObject = Parse.Object.extend('TestObject');
export var Post = Parse.Object.extend('Post');

or

var TestObject = Parse.Object.extend('TestObject');
var Post = Parse.Object.extend('Post');
export { TestObject, Post };

and import with

import { TestObject, Post } from '../store'

That is not valid syntax. You can do

export { Post }

or even just

export var Post = Parse.Object.extend('Post')

or shorten the whole file to

export default Parse.Object.extend('TestObject')
export var Post = Parse.Object.extend('Post')

Your imports are also incorrect, you'll want to do

import TestObject, { Post } from '../store'

This is if you really want a single default export and a separate named export. You can also just make two named exports and have no default if you want, e.g.

export var TestObject = Parse.Object.extend('TestObject');
export var Post = Parse.Object.extend('Post');

or

var TestObject = Parse.Object.extend('TestObject');
var Post = Parse.Object.extend('Post');
export { TestObject, Post };

and import with

import { TestObject, Post } from '../store'

const is like let, it is a LexicalDeclaration (VariableStatement, Declaration) used to define an identifier in your block.

You are trying to mix this with the default keyword, which expects a HoistableDeclaration, ClassDeclaration or AssignmentExpression to follow it.

Therefore it is a SyntaxError.

If you want to const something you need to provide the identifier and not use default.

export by itself accepts a VariableStatement or Declaration to its right.

The following is fineexport default Tab;

Tab becomes an AssignmentExpression as it's given the name default ^?

export default Tab = connect( mapState, mapDispatch )( Tabs ); is fine

Here Tab = connect( mapState, mapDispatch )( Tabs ); is an AssignmentExpression.

Update: A different way to imagine the problem

If you're trying to conceptually understand this and the spec-reasoning above is not helping, think of it as "if default was a legal identifier and not a reserved token, what would be a different way to write export default Foo; and export default const Foo = 1; ?"

In this situation, the expanded way to write it would be

// pseudocode, this thought experiment is not valid JS

export default Foo;
// would be like
export const default = Foo;

export default const Foo = 1;
// would be like
export const default const Foo = 1;
// so would the following line make sense?
const bar const Foo = 1;

There is a valid argument the expansion should be something like

// pseudocode, this thought experiment is not valid JS

export default const Foo = 1;
// would be like
const Foo = 1;
export const default = Foo;

However, this then would become ambiguous per Sergey's comment, so it makes more sense to write this pattern explicitly instead.

Simply export like this:

export default exportFrom

Or, using named export:

export {
  exportFrom,
  // you_can_export_any_number,
  // of_variables
}

For full reference see import and export

You can't have more than one default export.

Instead, use named exports.

// moduleName.js    

export const ConnectedUserList = connect(mapStateToProps, matchDispatchToProps)(UserList)

export const RealTimeApp = socketConnect(App);

Require the exports by name.

// otherModule.js
import { ConnectedUserList, RealTimeApp } from "./moduleName"

The export default {...} construction is just a shortcut for something like this:

const funcs = {
    foo() { console.log('foo') }, 
    bar() { console.log('bar') },
    baz() { foo(); bar() }
}

export default funcs

It must become obvious now that there are no foo, bar or baz functions in the module's scope. But there is an object named funcs (though in reality it has no name) that contains these functions as its properties and which will become the module's default export.

So, to fix your code, re-write it without using the shortcut and refer to foo and bar as properties of funcs:

const funcs = {
    foo() { console.log('foo') }, 
    bar() { console.log('bar') },
    baz() { funcs.foo(); funcs.bar() } // here is the fix
}

export default funcs

Another option is to use this keyword to refer to funcs object without having to declare it explicitly, as @pawel has pointed out.

Yet another option (and the one which I generally prefer) is to declare these functions in the module scope. This allows to refer to them directly:

function foo() { console.log('foo') }
function bar() { console.log('bar') }
function baz() { foo(); bar() }

export default {foo, bar, baz}

And if you want the convenience of default export and ability to import items individually, you can also export all functions individually:

// util.js

export function foo() { console.log('foo') }
export function bar() { console.log('bar') }
export function baz() { foo(); bar() }

export default {foo, bar, baz}

// a.js, using default export

import util from './util'
util.foo()

// b.js, using named exports

import {bar} from './util'
bar()

Or, as @loganfsmyth suggested, you can do without default export and just use import * as util from './util' to get all named exports in one object.