Review module and moduleResolution behaviour

[72636c]

Our base config currently sets moduleResolution to node:

skuba/config/tsconfig.json

Line 5 in 3bffa47

"moduleResolution": "node",

Per https://www.typescriptlang.org/docs/handbook/modules/reference.html#node10-formerly-known-as-node

--moduleResolution node was renamed to node10 (keeping node as an alias for backward compatibility) in TypeScript 5.0. It reflects the CommonJS module resolution algorithm as it existed in Node.js versions earlier than v12. It should no longer be used.

---

skuba build-package currently hardcodes modules:

skuba/src/cli/buildPackage.ts

Lines 9 to 20 in 3bffa47

	{
	command:
	'tsc --module CommonJS --outDir lib-commonjs --project tsconfig.build.json',
	name: 'commonjs',
	prefixColor: 'green',
	},
	{
	command:
	'tsc --module ES2015 --outDir lib-es2015 --project tsconfig.build.json',
	name: 'es2015',
	prefixColor: 'yellow',
	},

Per https://www.typescriptlang.org/docs/handbook/modules/reference.html#commonjs:

You probably shouldn’t use this [commonjs]. Use node16 or nodenext to emit CommonJS modules for Node.js.

[aurelius0523]

Hey @72636c, looking for some thoughts about the direction and scope that we should be looking for this. I had a crack at this one and I am hitting some roadblocks.

While the documentation seems to nudge users to go with Node16 for both moduleResolution and module, it seems like it will create a little too much friction. At least I feel that while I was testing those changes in this repo.

Some questions:

1. Do we still want to support both commonjs and esm when running skuba build-package? --module Node16 supports emitting both esm and commonjs in one outDir and that is a pretty different approach, since we have two outDirs, one for es2015 and commonjs respectively

   they are the only correct module options for all apps and libraries that are intended to run in Node.js v12 or later, whether they use ES modules or not.

2. Is there a general direction for the templates and packages like skuba-dive to go full esm? I don't think I notice any experience teams using skuba. skuba-dive currently supports node>=14.18, but it might not be too drastic to bump it to 16/18 since it looks we upgrade quite often at SEEK

I am unfamiliar with package maintenance, so happy to get any insight or feedbacks 😄

[AaronMoat]

Hey @aurelius0523!

1. For now, I think keeping support for both is important for SEEK.
2. Supporting ESM skuba projects might be a future plan, however it's a very tricky migration. We would do it for all of skuba, before requiring it in skuba-dive. See: Consider switching to ESM #398