Fix aggregated import and remove test for unsupported default export in TypeScript

[aweebit]

Please have a look at the commit descriptions for details.

ChangeLog

Fixed

• added missing createCommand, createArgument, createOption exports to TypeScript aggregated ESM import (import * as commander) when "esModuleInterop": true is set in TSConfig

Peer PRs

Changes are to be merged into…

• [Proof of concept] The ultimate TypeScript setup rework #1975

[shadowspawn]

The TypeScript aggregated/namespace import * as name uses a test when esModuleInterop: true which behaves in a surprising way which means the implicit createFoo routines are not accessible.

const commander = require('commander');

function test(x) {
  console.log(`${x}: ${Object.prototype.hasOwnProperty.call(commander, x)}`);
}

test('Argument');
test('createCommand');
test('program');
test('xyz');

commander.createCommand().parse(['--help'], { from: 'user' });

% node r.js
Argument: true
createCommand: false
program: true
xyz: false
Usage: program [options]

Options:
  -h, --help  display help for command

[shadowspawn]

Doing explicit exports for the exported properties fixes the issue, well worked out. I don't think it makes sense to test it because it is sensitive to the TypeScript settings which we choose for other reasons.

So just change index.js. (Not sure why @ts-ignore, not needed for current settings.)

This resolves the uncertainties mentioned in #1969.

[aweebit]

(Not sure why @ts-ignore, not needed for current settings.)

There was an error caused by circular references or something like that before, but I forgot under what circumstances and cannot reproduce it now. Removed the directives in d4a83fb.

I don't think it makes sense to test it because it is sensitive to the TypeScript settings which we choose for other reasons.

I think it should be tested with different settings then. My suggestion is to create two identical files just for the aggregated import tests and to transform them with different ts-jest configurations.

[shadowspawn]

I was previously testing two types of import. I still want to test both.

However, the aggregated import can test everything (especially the create routines!) rather than the now deprecated global object which was what I was worried about at the time.

[shadowspawn]

I don't think it makes sense to test it because it is sensitive to the TypeScript settings which we choose for other reasons.

I think it should be tested with different settings then.

Thinking about it more I do want to test both aggregated and deconstructed imports, since they do vary so unexpectedly in TypeScript, and can run same tests over both.

But I can't be bothered with actually setting up custom tsconfig with different configuration. Not even for just two of the many permutations that change the import implementation. I'll add notes in the PR where wrenching the config: #1969

[shadowspawn]

Current summary:

• obscure but good fix
• I want to test the "normal" destructed import in the ts test file, but ok with running same tests over the aggregated import properties in the same file.
• don't want to do tsconfig mucking about

[aweebit]

• I want to test the "normal" destructed import in the ts test file, but ok with running same tests over the aggregated import properties in the same file.

I have now added the normal import, but I am not sure the aggregated one is guaranteed to always behave the same when it is used together with the normal one and when used without it. Might be a better idea to, again, test them in separate files, like ts-import.aggregated.test.ts and ts-import.named.test.ts (this time without differing configs, though).

[shadowspawn]

Suggested change

	describe('commander', () => {
	describe('import * as commander', () => {

[shadowspawn]

(Or you were calling it aggregated import which would be ok too.)

[shadowspawn]

Suggested change

	describe('class name', () => {
	describe('named imports', () => {

[shadowspawn]

Might be a better idea to, again, test them in separate files, like ts-import.aggregated.test.ts and ts-import.named.test.ts (this time without differing configs, though).

That would be fine. (I checked the test does fail with double import when esModuleInterop: true, but agree that double import introduces some uncertainty.)

[shadowspawn]

Closing in favour of #2013, which lists @aweebit as co-author.