Remove TSDX from build system

[julianna-ciq]

resolves #1061

TSDX is a build system to uses rollup, prettier, eslint, and jest. It's helpful to use TSDX, because it will manage your build, lint, and testing procedures for you, instead of you having to manage all of those dependencies.

Unfortunately, TSDX hasn't been keeping those dependencies up-to-date, including the dependencies with vulnerabilities. If you have already cloned this repo, go to the main branch and run npm audit. You'll see 17 moderate vulnerabilities. Those vulnerabilities are all downstream of TSDX, and many of them are for features not even used in this repo. Furthermore, since TSDX relies on so many stale dependencies, it's reasonable to expect that problems will only continue to grow .

To overcome the risk presented by TSDX's stale dependencies, I've replaced TSDX with the rollup, prettier/eslint, and jest dependencies that it was obfuscating. Note that I copied over most of TSDX's configs for these tools, to maintain continuity.

The changes in this PR include:

• Linting: Added ESLint, plus plugins, and configured it to run in place of tsdx lint
• Testing: Added Jest, plus plugins, and configured it to run in place of tsdx test
• Building: Added Rollup, plus plugins, and configured it to run in place of tsdx build and tsdx watch
• Tidied up some of the scripts in package.json
• Added a clean script, which just removes the generated dist folder. This was convenient while I was rerunning builds to confirm that I was generating things correctly. Now, clean runs before every build to avoid the potential of hiding build errors.
• Linted some files. TSDX was using an older version of ESLint recommendations, so some files had to be re-linted to update to the latest recommendations. (Specifically, prefer-const)
• Updated a test. TSDX was using an older version of jest/jsdom. When I updated to the latest jest, I had to enable legacy timer mocks in one of the testing files.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: julianna-ciq / name: Julianna Langston (4f6f578, eb128eb, f189534, e8a2c8b, 528bb40, 84673cf, fa489ab, 7e0a5e2, f52aec3)
• ✅ login: kriswest / name: Kris West (b4d6482, 8fa9037, adca3ad, c359610, 80552fe, c2cb9d5, c9d0806, e59fdc9, 0b3bf81, 69af9da, 4d3bd02, 60ea695, 22afac0, 61e1866, 27056d4)

[netlify]

✅ Deploy Preview for fdc3 ready!

Name	Link
🔨 Latest commit	27056d4
🔍 Latest deploy log	https://app.netlify.com/sites/fdc3/deploys/6630e48c316c670008444262
😎 Deploy Preview	https://deploy-preview-1175--fdc3.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[kriswest]

Fixed clean on windows and build on linux - module needs testing in the field, but otherwise LGTM. Many thanks for taking this on @julianna-ciq

[bingenito]

Tested all changed commands on windows (command prompt) and RHEL9 and look good. Also very happy to see npm install complete with 0 vulnerabilities.

[bingenito]

@julianna-ciq Where are these native bindings used? Should we add the windows and darwin as optional and let npm work out which to install?

[kriswest]

I added this after it started blowing up on netlify/github actions. Doesn't seem to need the window version declared though (just works there). I haven't tested on a mac - all you need to do to check is npm run build.

[bingenito]

I added this after it started blowing up on netlify/github actions. Doesn't seem to need the window version declared though (just works there). I haven't tested on a mac - all you need to do to check is npm run build.

Just tested mac again after linting issue was fixed and it is all good.

[kriswest]

We only had a couple of minor types conflicts in finsemble when we dropped the new module in - one relates to a change that should only go out in 2.2.0 that's already merged and the second maybe a type issue caused by that first one. Hence, I'll figure out what to do to back out the change temporarily so we can get this released!

[kriswest]

The change that needs backing out is:

• Remove the IntentResolution.version field as defunct #1170

[bingenito]

Did it always build upon npm install? I now get eslint failures that I wasn't seeing on last test -

> @finos/fdc3@2.1.0-beta.8 lint
> eslint src/ test/ --ext .ts --fix

C:\Users\brian\Source\FDC3\src\context\ContextType.ts
  46:85  error  Don't use `{}` as a type. `{}` actually means "any non-nullish value".
- If you want a type meaning "any object", you probably want `object` instead.
- If you want a type meaning "any value", you probably want `unknown` instead.
- If you want a type meaning "empty object", you probably want `Record<string, never>` instead.
- If you really want a type meaning "any non-nullish value", you probably want `NonNullable<unknown>` instead  @typescript-eslint/ban-types

C:\Users\brian\Source\FDC3\src\intents\Intents.ts
  32:49  error  Don't use `{}` as a type. `{}` actually means "any non-nullish value".
- If you want a type meaning "any object", you probably want `object` instead.
- If you want a type meaning "any value", you probably want `unknown` instead.
- If you want a type meaning "empty object", you probably want `Record<string, never>` instead.
- If you really want a type meaning "any non-nullish value", you probably want `NonNullable<unknown>` instead  @typescript-eslint/ban-types

✖ 2 problems (2 errors, 0 warnings)

[kriswest]

It did indeed always build on install, not sure why.

These two new eslint errors are from:

• Refactors ContextTypes&Intent to union type instead of enum #1139

We'll should adjust as it suggests to clear them out...

[kriswest]

@bingenito @andreifloricel it took me a little while to understand what was going on here (https://github.com/InteropIO/FDC3/blob/c2cb9d51e8644ac64e3640b1eb0cb95bb9cc8d5b/src/context/ContextType.ts#L46-L48).

It would be nice if, when using the type, if Intellisense or similar was proposing the standard types for you - although you can create your own so any string is allowed:

export type ContextType = StandardContextType | ExperimentalContextType | string;

However, the typescript compiler aggressively reduces that to just string, which is correct for type safety, but useless for autocomplete. @andreifloricel clearly knows this and used the standard workaround

export type ContextType = StandardContextType | ExperimentalContextType | (string & {});

However, that trips the modern linting rule @typescript-eslint/ban-types. I couldn't find another composition that achieves the same, so I've just disabled that linting rule for the two lines concerned, and all is well again.

[kriswest]

@bingenito latest version should no longer typegen & build on npm install. Switched to prepack from prepare.

Also @julianna-ciq fixed the missing dist/index.js file, which was being generated by a custom feature (custom rollup plugin) of TSDX:

https://www.unpkg.com/browse/@finos/fdc3@2.1.0-beta.6/dist/index.js <- TSDX
https://www.unpkg.com/browse/@finos/fdc3@2.1.0-beta.9/dist/index.js <- new build