Bugfix/disable module in harmony

[sokra]

What kind of change does this PR introduce?
bugfix

Did you add tests for your changes?
yes

If relevant, link to documentation update:
N/A

Summary
emit errors if using AMD or CommonJS syntax in harmony modules
and some refactorings needed for this

Does this PR introduce a breaking change?
yes

[TheLarkInn]

Looks good. Still working on this?

[Jessidhia]

class ModuleDependencyError extends Error {
  constructor(module, err, loc) {
    super(`${formatLocation(loc)} ${err.message}`);
    this.name = "ModuleDependencyError";
    this.details = err.stack.split("\n").slice(1).join("\n"); // err.stack.replace(/^./g, "")?
    this.origin = this.module = module;
    this.error = err;
  }
}

Calling Error.captureStackTrace is not necessary on native subclasses. The message can also just be given as the super argument instead of assigning to this.message. However, not calling Error.captureStackTrace does leave the constructor itself as the top of the stack trace.

[Jessidhia]

const

[Jessidhia]

All of these should only match if the user doesn't shadow them with their own binding, otherwise this would prevent using e.g. module as an identifier (as often happens in webpack's own code).

[sokra]

The Parser should automatically handle this. But I'll add a test case validating it.

[Jessidhia]

Any escape hatch (or alternative) for module.hot? Or it is not a problem as a more specific expression module.hot plugin would run before?

[sokra]

expression module.hot will run before expression module. As expression module.hot returns false it stops traversion.

[sokra]

This is already tested by the HMR testcases for harmony modules.

[Jessidhia]

class CommonJsInHarmonyWarning extends Error {
  constructor (name) {
    super(`${name} is not allowed in EcmaScript module: This module was detected as EcmaScript module (import or export syntax was used). In such a module using '${name}' is not allowed.`)
    this.name = "CommonJsInHarmonyWarning"
  }
}

[Jessidhia]

export { xa, xb, xc as xc, xd as xd } from "./module"?

or is this specifically checking export of imported symbol?

[sokra]

This is an old test and I didn't want to change it more than necessary.

[TheLarkInn]

Looks good.

[TheLarkInn]

The Parser should automatically handle this. But I'll add a test case validating it.

Sorry I missed this. @sokra do you want a separate issue for that?

[sokra]

uh you already merged it...

I'll create a new PR...