v10.0.0 Q&A

[cspotcode]

This discussion thread exists to ask questions about the new version. If anything in the release notes is confusing, or if you encounter problems with the upgrade, you can post your questions below.

Release notes

Many of the breaking changes in v10.0.0 will only affect very rare cases. For the vast majority of users, these changes will have no effect. Some improve ts-node's automatic behavior in special cases, such as writing portable shell scripts that live on your $PATH or are executed with npx without any compilation or boilerplate. Others more closely align our behavior with vanilla node. They are intended to improve quality-of-life for all users.

As needed, we can explain these changes in greater detail in threads below.

[mxfactorial]

@MoutPessemier avoids babel when testing with jest in https://github.com/MoutPessemier/enhancedMathJS

"ts-node": "^9.0.0" passes the jest.config.ts without error:

1. git clone https://github.com/MoutPessemier/enhancedMathJS.git
2. cd enhancedMathJS
3. git checkout 3193d6c6b2246939dc7fe6d83ed09613da9f25ea (before v10 bump)
4. npm install
5. npm test

 PASS  src/__tests__/transpose.spec.ts
 PASS  src/__tests__/matrix_product.spec.ts
 PASS  src/__tests__/matrix_sum.spec.ts
 PASS  src/__tests__/fibonacci.spec.ts
 PASS  src/__tests__/factorial.spec.ts
 PASS  src/__tests__/discriminator.spec.ts
 PASS  src/__tests__/permutation.spec.ts
 PASS  src/__tests__/combination.spec.ts
 PASS  src/__tests__/matrix_utils.spec.ts

Test Suites: 9 passed, 9 total
Tests:       84 passed, 84 total
Snapshots:   0 total
Time:        3.854 s
Ran all test suites.

but switching to "ts-node": "^10.0.0" errors on npm test:

TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts" 

and passing a node loader option to the "test": "NODE_OPTIONS=\"--loader ts-node/esm\" jest" script in package.json errors with:

ReferenceError: exports is not defined

then ts-node@10.0.0 hangs when compilerOptions.module = "ESNext" and compilerOptions.target = "ESNext" in tsconfig.json

solution for packages not exporting in es6:

• remove module type from package.json

[cspotcode]

Ah yes, avoiding node's ESM and sticking to CommonJS is once again the right decision. :)

For what it's worth, it appears that enhancedmath@2.9.0 might be broken. npm install and require() fails because it's commonJS but has been marked "type": "module" https://github.com/cspotcode/repros/tree/node-esm-issue

It looks like jest overrides compilerOptions.module to be commonJS when it loads ts-node. This is smart because it means jest.config.ts will always compile as commonJS. The problem is that ts-node v10 aligns with node's behavior to throw an error when you try to require() an ESM file, so when you set your package to be "type": "module" you get an error. (node throws the same error for jest.config.js)

I'm gonna have to talk to the jest folks about this.

[cspotcode]

#1371 should give users a way to force CJS when they need it, solving this use-case. I just finished the implementation minutes ago and haven't reviewed it, but it has basic tests that are passing.

If you're feeling adventurous you can install from git:

npm install -D TypeStrong/ts-node#ab/override-module-type

[jayaddison]

Upgrading to ts-node 10.0.0 led me to encounter what I thought at the time might be a regression, as reported in #1368. In brief: a library (that has "type": "module" configured in package.json) that compiled and ran using ts-node 9.x began failing to compile.

As explained by @cspotcode in that issue, this is not a regression and it is a change called out in the release changelog:

Here is the relevant changelog entry:

• [BREAKING] Fix Make attempts to require() ESM *always* throw error #1229 and assertScriptCanLoadAsCJS() can trigger self when loading assertScriptCanLoadAsCJSImpl #1235: always throw ERR_REQUIRE_ESM when attempting to execute ESM as CJS, even when not using --loader ts-node/esm (Fix #1229 and #1235: [BREAKING] always throw ERR_REQUIRE_ESM when attempting to execute ESM as CJS, even when ESM loader is not loaded #1232)

The fix to unblock an upgrade is a work-in-progress at the moment; I like the sound of migrating to CommonJS (also called cjs) if possible, although doing that will depend on making sure that the application that depends on the library is able to adapt to that migration.

Removing "type": "module" from package.json should aid in switching back to CommonJS as I understand it, but tests currently continue to fail with that change applied (the codebase after that removal can be found here).

Note: one peculiarity -- potentially relevant to TS compilation -- of this codebase is that it includes a module self-dependency. It's a series of what are essentially database migrations, and the idea is to be able to deploy a JS application that at any time includes a full series of those migrations (A->B->C) using NPM's dependency management and resolution instead of having to rely on filename ordering and/or migration IDs to enforce a migration graph).

I'd appreciate any help and references regarding completing the migration to CommonJS -- or, equally, suggestions about why other approaches might be better.

[jayaddison]

Yep, that's a traditional and well-understood approach towards data migration, so it's almost certainly what I should do..

..however, I'm trying to develop an application that can - in theory - work in a multi-peer environment where clients may be on different versions -- and thus have data stores versioned differently -- and yet be able to co-ordinate by finding closest-common commit graph points, and then (perhaps temporarily, for the duration of each communication session) use data migrations to bring each peer's data back/forward to format as-specified at that common point.

All a bit mad and impractical probably, but I think technically feasible. The long and short of it is that it means I'd like to keep the commit reference approach, at least for now. The closest thing to a description of this kind of data architecture 'in the literature' that I've been able to find is Cambria if you're curious at all.

On a more practical point regarding EJS / CommonJS builds for the module -- yep, ok. Let me take a bit more look at that in detail and try to understand the implications of the build configuration. I'll admit to not being hugely familiar with different JavaScript variations and the processes that transpile them; it'll take me a little while to get up to speed but I'll get there.

[jayaddison]

(also, thank you for taking the time to look into this)

[cspotcode]

You may have luck using #1371, which allows ts-node to override the package.json "type" field for files that it transforms. I just finished the implementation minutes ago and haven't reviewed it, but it has basic tests that are passing.

[jayaddison]

Using dcbd916 from ab/override-module-type allows the application to build and tests to pass, thank you @cspotcode. Let me know if I can provide any further testing or help with #1371 ; openculinary/frontend@ca3a227...6eb41a6 shows the changeset applied.

[cspotcode]

That would be great, my time has been temporarily diverted to some swc bugfixes.

For #1371, there are 2x remaining TODO items: --showConfig and missing test coverage. I think we can safely postpone the --showConfig changes, but we need to add the missing test coverage. If you're interested, please comment on #1371 and I can offer guidance over there. Our tests may look intimidating at first, but I've found they are pretty straightforward to write since they are mostly e2e-style (they run the CLI against sample code and make sure it spits out some correct stdout messages)