New module related issues when upgrading

Description

Upgrading from @master-chief/alpaca ^3.6.3 → ^4.2.3

I’ve just begin to dig on these to… but in case they are some other quick ones. Both of these are new for me (the cdk synth one involves bundling with esbuild):

eikeon@iMac matic % npm run build

> matic@0.1.6 build /Users/eikeon/matic
> tsc

eikeon@iMac matic % npm run cdk synth

> matic@0.1.6 cdk /Users/eikeon/matic
> cdk "synth"

Bundling asset MaticPipeline/PreProd/Matic/handler/Code/Stage...
 > ../node_modules/node-gyp-build/index.js: warning: Indirect calls to "require" will not be bundled (surround with a try/catch to silence this warning)
    6 │ var runtimeRequire = typeof __webpack_require__ === 'function' ? __non_webpack_require__ : require // eslint-disable-line
      ╵                                                                                            ~~~~~~~

1 warning
Successfully synthesized to /Users/eikeon/matic/cdk.out
Supply a stack id (MaticPipeline, MaticRepo) to display its template.
eikeon@iMac matic % node_modules/.bin/ts-node t.ts                                                                                                                                             
Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /Users/eikeon/matic/node_modules/@master-chief/alpaca/dist/mjs/index.js
require() of ES modules is not supported.
require() of /Users/eikeon/matic/node_modules/@master-chief/alpaca/dist/mjs/index.js from /Users/eikeon/matic/lib/matic-stack-handler.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
Instead rename index.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from /Users/eikeon/matic/node_modules/@master-chief/alpaca/package.json.

    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1080:13)
    at Module.load (internal/modules/cjs/loader.js:928:32)
    at Function.Module._load (internal/modules/cjs/loader.js:769:14)
    at Module.require (internal/modules/cjs/loader.js:952:19)
    at require (internal/modules/cjs/helpers.js:88:18)
    at Object.<anonymous> (/Users/eikeon/matic/lib/matic-stack-handler.ts:2:1)
    at Module._compile (internal/modules/cjs/loader.js:1063:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1092:10)
    at Module.load (internal/modules/cjs/loader.js:928:32)
    at Function.Module._load (internal/modules/cjs/loader.js:769:14)
eikeon@iMac matic % 

[117]

@117 you can give it a try, but it will be painful. I have a project working just fine with the setup above.

What would be really useful is an example reproduction of the problem. Then we could get to the bottom of it.

I experienced the issue he was facing when trying to use the same compiler. Without taking extra steps new users of ts-node will hit the same wall. While there is a way around it, its actually more complicated than just adding cjs compilation for legacy support on our end. The JS community really hasn’t progressed enough to ditch it entirely IMO.

[husayt]

@eikeon since node 14 (current LTE) supports es modules, there was no much point to cling to commonjs. Besides, that allowed us to properly support browsers and other combinations: Cuurently these bundles are provided:

• alpaca.js - ESM bundle (for node)
• alpaca.bundle.js - ESM bundle with dependencies (for node)
• alpaca.browser.js - UMD bundle (for browser)
• alpaca.browser.modern.js - ESM modern bundle (for browser)