Improve module environment inheritance with a Object.create like

[leobalter]

Ref #859 (comment)

Instead of using QUnit's extend method to extend a module's env. inheritance, we should improve it with a Object.create's like inheritance.

Suggested by @gibson042:

var createObject = (function( Base ) {
    return function( prototype ) {
        Base.prototype = prototype;
        return new Base();
    };
})( Function() );
…
env = createObject( parentModule.testEnvironment );

We could also use Object.create adding a polyfill that would be used only on IE6~IE8 for the supported browsers.

[jzaefferer]

Sounds good to me. Would help to see an actual implementation.

[jzaefferer]

For the Object.create polyfill, we can inline that without the comments, but with a // Support ... comment.

[leobalter]

I want to investigate using LoDash's _.create as we might use _.isEqual in #865

[jzaefferer]

Good idea. It'll be a while until I can get back to working on the build to include lodash modules, so feel free to take that over.

Maybe we should start by trying to switch to ES6 modules (again), with rollup? Then add more dependencies from there.

Or maybe using webpack? I had good experience with that on other projects. It would certainly deal well with a mix of internal ES6 modules and external modules, in whatever format.

[trentmwillis]

Is this still desired? Since we now support IE9+ we could use Object.create directly, but I'm unsure what benefit this gives us over using the current extend implementation.

[gibson042]

The biggest reason for this issue was ensuring that every test has a distinct environment based on its module's environment and shared with the entire before/beforeEach queue and afterEach/after stack, and that is already fulfilled per #859 (comment) . There's still value in actual inheritance over shallow copying, but I think it's exclusive to sugar for advanced asynchronous use cases (and "sugar" in the sense that they can still work without it). For example:

QUnit.module("outer", function( outerModule ) {
	// Load an ES2018 module into this environment, asynchronously
	// cf. https://github.com/tc39/proposal-dynamic-import
	this.dynamicModulePromise = import("./dynamicModule.js")
		.then( module => this.dynamicModule = module );

	QUnit.module("doesntNeedDynamicModule", function( innerModule ) {
		QUnit.test(…);
	});
	QUnit.module("needsDynamicModule", function( innerModule ) {
		innerModule.before( () => await this.dynamicModulePromise );
		QUnit.test(…);
	});
	QUnit.module("alsoNeedsDynamicModule", function( innerModule ) {
		innerModule.before( () => await this.dynamicModulePromise );
		QUnit.test(…);
	});
});

I'm cool with closing it.

[Krinkle]

Closing for now. Not having live inheritence here I think actually makes the test runner slightly easier to reason about, and would also be a theoretically breaking change that will be hard to explain.

Having said that, for future readers: There is no strong opposition to this, so if you find a particular use case is impossible or very hard without this, feel free to create a new issue and we'd likely be open to reconsidering it and/or accepting a patch :)