chore(typescript): upgrade and switch to nodenext

@petermetz When implementing Iroha V2 support in cactus I encountered some problems with @iroha2/client package. Their team provided some solution, but they require the use of moduleResolution of nodenext. This also requires upgrade of TS to 4.7. We will opt for a package that supports our current moduleResolution/typescript but, just in case and for the future, what is your opinion regarding such change?

Here’s info on nodenext modules: https://www.typescriptlang.org/docs/handbook/esm-node.html

[aldousalvarez]

Hello @petermetz here is the initial report about how much effort it would be to upgrade typescript to 4.7 and switch the moduleResolution to nodeNext

• Upgrading the typescript to 4.7

Minor updates on some of the files with few upgrades on its dependencies.

• Migrating the moduleResolution to nodeNext

Based on the solution from ECMAScript Modules in Node.js, majority of encountered errors are due to new implementation of import policies. Here are some of the changes that bring a few high-level features that you can see below:

-type in package.json and New Extensions Node.js supports a new setting in package.json called type. “type” can be set to either “module” or “commonjs”.

{ “name”: “my-package”, “type”: “module”, “//”: “…”, “dependencies”: { } } This setting controls whether .js files are interpreted as ES modules or CommonJS modules, and defaults to CommonJS when not set. When a file is considered an ES module, a few different rules come into play compared to CommonJS:

1. import/export statements and top-level await can be used
2. relative import paths need full extensions (e.g we have to write import “./foo.js” instead of import “./foo”)
3. imports might resolve differently from dependencies in node_modules
4. certain global-like values like require() and __dirname cannot be used directly
5. CommonJS modules get imported under certain special rules

After switching to nodeNext the errors come in batches with 8 to 12 dependecy errors. I have modified/updated 83 files and added 1 file to declare a package so that it would be imported.

As of now files has been tested using “yarn run test:unit” and “yarn run test:integration”. Based on the latest commit all the test results are equal on the test:unit (15 suits and 151 asserts passed to 15 suits and 151 asserts passed) and with more passing results in test:integration (79 suits and 1491 asserts passed to 80 suits and 1499 asserts passed).

EXAMPLE OF THE CHANGES APPLIED:

Before: import { AppModule } from “./app/app.module”; import { environment } from “./environments/environment”;

After import { AppModule } from “./app/app.module.js”; import { environment } from “./environments/environment.js”;

Before import { RuntimeError } from “run-time-error”;

After const { RuntimeError } = require(“run-time-error”);

1. (Similar solution used with this issue) Before const { version } = await import(packageFilePath);

After const packageFilePathJson = JSON.parse( readFileSync(packageFilePath, “utf8”), ); const { version } = packageFilePathJson;

Before import { NodeSSH, Config as SshConfig, SSHExecCommandOptions, SSHExecCommandResponse, } from “node-ssh”;

After import { NodeSSH, ConfigGiven as SshConfig, ExecOptions as SSHExecCommandOptions, ExecResult as SSHExecCommandResponse, } from “node-ssh”;

1. Also tried to use the new “type”; “module” into some of the packages:

examples/cactus-example-carbon-accounting-frontend/package.json examples/cactus-example-supply-chain-frontend/package.json

[aldousalvarez]

Update from the latest commit:

yarn run test:integration is now having more passing results (from 80 suits and 1499 asserts passed to 83 suites and 1558 asserts passed). based on 79 suits and 1491 asserts passed from clean testing without any changes