unit tests and third party dependencies

[baywet]

Category

• Question
• Typo
• Bug
• Additional article idea

If you are planning to share a new feature request (enhancement / suggestion), please use SP Dev UserVoice at http://aka.ms/sp-dev-uservoice.

Expected or Desired Behavior

Importing a dependency for unit testing that relies on es6/2015 should work. (transpilation should be implemented for things in node_modules)

Observed Behavior

PhantomJs systematically fails when writing any unit tests that rely on a library using es6/2015 with error messages similar to this one.
PhantomJS 2.1.1 (Windows 8 0.0.0) ERROR SyntaxError: Use of reserved word 'let' in strict mode
(eventually the error with PhantomJS will be solved when they ship 2.5 with es2015/6 support, however we'll still run into that with IE and Safari unit tests)

Steps to Reproduce

Implement a unit test like this one for a webpart and install chai-as-promised 7+ as well as @types/chai-as-promised

/// <reference types="mocha" />
/// <reference types="chai-as-promised" />
import * as chaiAsPromised from "chai-as-promised";
chai.use(chaiAsPromised);
describe("DevOpsWebPartWebPart", () => {
  it("should add numbers async", () => {
    const asyncResult:Promise<number> = Promise.resolve(3);
    return asyncResult.should.eventually.equal(3);
  });
});

Related issues

ariya/phantomjs#14506
chaijs/chai-as-promised#207
chaijs/chai-as-promised#211

[iclanton]

We don't currently support transpilation of es6 modules out-of-the-box. We investigated it a long time ago, but Babel was far too slow. The reason this happens is because Karma produces a webpack bundle containing the test code and its dependencies, and webpack passes through the es6 code.

There are a couple of options for you/us/everyone:

• Write your own babel transpilation task and run it before bundling. You can create an ad-hoc build task and register it to run after the TypeScript compilation, and update your references to point to the drop location from your task. Information about writing build tasks is here.
• If there's enough demand, we can write a babel transpilation task that can be configured to run against certain files. The build framework that our build tools are built upon are hosted here if you're interested in putting a task together and contributing it :).
• Check out Jest. Jest doesn't require bundling the way Karma does, so it'd avoid the problem entirely. We're exploring Jest internally right now, and we'll probably get a public Jest task released eventually.
• Use a non-es6 library. This is probably the least appealing option, but it'll work without any extra effort.

[baywet]

Thanks for the exhaustive answer Ian,
A lot of libraries lately are transitioning to es6 and don't provide anymore bundles/dists with shims and retro-compatibility and maintainability reasons, and in a web world it makes sense, it came out more than 2 years ago already.
Now from a SPFX perspective with have a few different populations: new developers, old SharePoint developers (those two don't know much about all the modern tooling), modern web developers (non-SharePoint) and edgy SharePoint developers.
Out of four, two segments of that population would not be able to implement such thing easily and instead of digging the subject, would probably drop writing unit tests.
The last two segments would probably be able and implement it, but that's going to add to the "why is SharePoint development so complicated?" image which the SPFX is trying to get rid off.
So I think this is something the SPFX team should spend time on, then again I know there's a sense of priorities.
Now the Jest solution is interesting: SPFX is framework agnostic (React, Knockout, hopefully Angular...) shouldn't it be testing framework agnostic and provide multiple options?
On the PR side for web-tools: would you rather see an augmentation of @micorosoft/gulp-core-build-karma or another module? (Am I looking at the right module to begin with?)

[baywet]

Thanks for the follow up @lahuey however there was still one question left. In case of a PR on web tools to add babel (or something else) to the pipeline for unit tests, would you rather have a new modules or just a new task under an existing module? If second option, which one? CC @iclanton

[iclanton]

It would probably be simplest as a new post-TS task. It's pretty simple to put together an ad-hoc task in your gulpfile.

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues