Evaluate what is needed to make ESM and TS support more seamless

[morrinene]

• Moving Intern's AMD plugins into another format so that they work with ES6
• Support other loaders, such as SystemJS

Related issues

feel free to remove anything not relevant

• Feature Request: use SystemJS as the default loader (or at least support it) Feature Request: use SystemJS as the default loader (or at least support it) #615
• Feature Request: Write tests in ES6 Feature Request: Write tests in ES6 #626
• Allow loader config in file(s) Allow loader config in file(s) #493

[morrinene]

Some questions:

ESM support/workflow (how it works now)
Work through how ESM is used to author and structure tests
How does Intern 4 load dependencies? How does someone include a loader for testing and/or running their app (is that a relevant question)
Do we need any dynamic behavior to replace loader plugins?
How do we replace usage of dojo/has?
Anything special with how we distribute our packages
Anything special with test authoring structure or workflow to document?

[bryanforbes]

ESM support/workflow (how it works now)

Right now, ES modules must be transpiled into UMD or AMD modules in order to be loaded by intern. Test modules can be authored as ES modules, but because intern's module ID interface uses AMD plugins, those modules cannot be loaded by an ES module loader.

Work through how ESM is used to author and structure tests

I don't see (other than the AMD plugin module IDs) how authoring tests in ES modules would be substantially different than how they are authored today

How does Intern 4 load dependencies? How does someone include a loader for testing and/or running their app (is that a relevant question)

I believe that Intern 4 (or possibly 5) should fundamentally change how it loads modules. To me, there should be some clear separations (forgive me if I use the wrong technical terms):

• harnesses: interfaces for registering tests
• assertions: interfaces for asserting test conditions
• runner: mechanism for running tests registered with the test harnesses
• loaders: mechanisms for loading test modules in environments
• reporters: mechanisms for reporting test results

Right now, Intern 3 has all 5 of these, but the runner and loader are conflated (for historical reasons). I would like to see the runner and loaders separated. For a browser environment, I could see Proxy sending the user's configuration, test runner, and the selected loader (AMD, SystemJS, etc.) inlined into the page. The runner would not need to know how to load things, but would offload that responsibility to the loader. Something similar could be done in Node.

Do we need any dynamic behavior to replace loader plugins?

In my opinion, no. Intern currently uses AMD plugins to simplify loading test harness interfaces (intern!bdd -> intern/lib/interfaces/bdd) and the assertion interfaces. If we break the test harness and assertion interfaces into their own packages, there will be no need for simplifying library paths.

How do we replace usage of dojo/has?

From what I can see, dojo/has is mostly used to determine if Intern is running in Node or the Browser. Given this usage, the Proxy or Node runner would determine which environment to set up for the test runner.

Tests using dojo/has to load specific tests for a specific environment could be broken out and the tests could be determined based on a command line flag in Intern's configuration.

Anything special with how we distribute our packages

We would need to have a "core" package that would contain the generic test registration interfaces (like lib/Test.js, lib/Suite.js, etc.), browser runner, node runner, proxy, and configuration parser. From there, the harnesses, assertions, loaders, and reporters would be broken out into their own packages. Users would choose which of these latter packages they want to use and only bring in what they need.

Anything special with test authoring structure or workflow to document?

Authoring shouldn't change much. Users using AMD now can use an AMD loader, users wanting to use SystemJS can use that loader, etc.

Workflow might change since how Intern works would fundamentally change. We would need to document that as we encounter workflow changes.

[devpaul]

@jason0x43 suggested we could remove much of the need for has by creating suite configurations based on the engine in #669.

Intern could use some improvement in selectively running tests. For instance, if you want to conditionally register functional tests based on browser support, e.g. the test machine supports 4k resolution, there is no way to do this and skip() only works at the test level. Maybe we could support skip() in before() so the rest of the suite is skipped and the tests are still reported as part of the run?

Also, I'm all for splitting out Intern into separate packages as long as we still bring it all together under a single intern package. What are your thoughts on this?

If the loader is externalized then how will Intern load suites provided to it in it's configuration? To keep it like it is, I assume we'll need a way to dynamically load modules, either by creating a wrapper around popular loaders (dojo-loader, SystemJS, WebPack, etc...) or we'd need to only use Intern programmatically and do away with the configuration-driven approach.

[bryanforbes]

Also, I'm all for splitting out Intern into separate packages as long as we still bring it all together under a single intern package. What are your thoughts on this?

That seems like a good idea: if someone wants a basic/standard install, they can use the intern package.

If the loader is externalized then how will Intern load suites provided to it in it's configuration?

The loader mechanism (which would be inlined into the environment) would read the inlined intern configuration and do its thing. The inlined configuration could (should?) have paths to the files resolved (especially for globs) so the loader doesn't have to do any crazy path manipulation.

creating a wrapper around popular loaders (dojo-loader, SystemJS, WebPack, etc...)

That's my thought. A small wrapper around the loader API or a hook to tell intern how to inline the loader (or loader script tag) into the environment.