Feat/core packages post merge udpates

[shanefontaine]

Simplify and cleanup after config updates.

All TS, lint, and test configs live at the root of the monorepo & each package only extends and adds what they need, if anything. Most per-package configs are pass-through files and only exist to help developers understand the structure of the package (i.e. if there is a jest.config.mjs I know the package is testing using jest) and for tooling to easily understand where to look without changing the defaults of every tool.

Almost every non-config file change in this PR is a lint. The valuable changes to observe are only the config files.

Config

TS Config

• Use NodeNext for module and moduleResolution at the top-level tsconfig.json since this will likely be the default for the way we use most packages. Individual packages can explicitly choose others.
  • My personal understanding is that NodeNext will work in effectively all cases. For packages bundling ESM (sdk, frontend), we use ESNext and Bundler for the ESM build since that gives the bundler the most flexibility to work with.
  • Another reason is because moduleResolution default for module: "ESNext" is node, which "...should not be used for new projects.".
  • Other references
  • “Matt’s advice, my usual advice, and the TypeScript documentation’s advice is that you’re usually basically fine to use nodenext for all libraries” Andrew Branch (Basically author of all module logic on TypeScript and referencing Matt Pocock (TS Dev Advocate that has awesome TS articles)
  • “node16 and nodenext 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.” TS Docs
  • “In short, "moduleResolution": "bundler" is infectious, allowing code that only works in bundlers to be produced. Likewise, "moduleResolution": "nodenext" is only checking that the output works in Node.js, but in most cases, module code that works in Node.js will work in other runtimes and in bundlers.” TS Docs
• Removed per-package-dir tsconfig (i.e. ./sdk-core/src/tsconfig.json). The initial intention was to treat each subdir (i.e. src and test) as individual modules and then reference each other. This satisfied all builds and tooling. However, this is only required if multiple subdirs are being built. If there is only a single subdir being built, src, and one that is not emitted, test, then references are not necessary and everything, including tooling, works as-is.
  • This then means we have to test dual packages as CJS instead of ESM. This is expected and is actually the way I intended originally, though I had set it up incorrectly. The test format (CJS vs ESM) does not affect the build output format consumed by integrators.

Packages

All

• For ESM packages, removed ts-node in favor of tsx. Added watch script to all relevant packages. New flow to run a backend package is watch then start.
  • tsx runs on compiled code which is why watch is added. I would still prefer ts-node (or something similar) but spent hours trying to get it to work correctly without crazy config or unintuitive stuff. I think the project is slowly dying -- see all the open issues about this. Happy to go with another package that achieves this same goal if there is one.

hop-node and hop-node-core

• Require explicit type qualifier for import/export types. Helps explicitness with ESM packages via verbatimModuleSyntax tsconfig rule as well as DX internally (IMO) via linting rules.

sdk and sdk-core

• Removed top-level builds from SDK packages. My understanding is that they allowed for import from a deeper path (@hop-protocol/sdk/networks) but new dual CJS/ESM with modern exports defined achieves the same without the additional build step.
• Remove typechain and subsequently the need to do manual (via npm scripts) copy/pasting of ABI stuff as well as scripted format fixes.
  • Note: The upside and ultimate goal of this exercise is that we are free from the constraint that typechain would always have on us in v2 and beyond since we used it in sdk-core -- we can now plug in whatever tool we want (after figuring out what the best is). The downside of this is that it is more difficult to add new contracts until the new tool is adopted. Given the static nature of these dirs, I believe this is ok. If we need to add a new contract, we can just run an independent typechain run on the single contract. The ultimate goal, however, would be to just use the latest tooling and not deal with any of this, however, I know this is easier said than done.
• Removed ts-nocheck script from sdk and sdk-core. They are no longer needed with updated TS config.

V2 Explorer Backend

• Convert package to pure ESM. Removes legacy logic like module_aliases and simplifies aliases. Standardizes syntax with other packages in our monorepo for easier internal DX.

Tooling

Linting

• Updated to eslint@9.0.0 (released on Fri, April 5th). Updated all packages to use new default flat config. All rules remain the same
• Updated lint rules to avoid the task from linting dist/build/etc (this was the reason for the long lints last week was this)

Other

• Remove hoisted react-router that was required for pre-vite packages.
• Updated entire repo to use Node 20.12.1 over 20.10.0. It is still the same major, the new LTS, and updated for latest security release.

[netlify[bot]]

❌ Deploy Preview for hop-sdk-docs failed.

Name	Link
🔨 Latest commit	24ee9ef56e512c051f392d1ad712e796d507cedf
🔍 Latest deploy log	https://app.netlify.com/sites/hop-sdk-docs/deploys/6615c171847a01000817db0a

[shanefontaine]

@miguelmota

• Added typechain explainer (19ae7757735affd33dfecaded24fad2aff3fd067) (8ddc2e0f2c089b68fb6fdc2d816f054d4e1a35c2)
• Move abi in sdk and sdk-core to top-level, check into repo, and remove from build (a82e905e32cc190dfe1ff0ab3135a2f9abc3cb44)
• Removed stream-browserify from FE. It built just fine on my machine without it (5a10cf1571fca9e13362fc3a9018a962bf2a985f)

I really like the new top-level, not built ABI. Only thing I don't love is the use of X__factory throughout, but I see that as a remnant of tyepchain and whenever we find a replacement we can just replace that with something more friendly and requiring less context.

[miguelmota]

@shanefontaine looks great 👍

[shanefontaine]

@miguelmota Ready to merge whenever.

• Introduce Husky. Happy to discuss/change/remove, very loose opinion on this. (c9f1d61d0ab0709bca5ea014f1fb458576db29be)
• Use wilcard to include all packages in worksapce (1cfcade7ad06c2b41d89ce4b1afea5fcd0ba9afe). I think I like this but down to revert if desired.
• Update and remove deps
  • Dependabot (https://github.com/hop-protocol/hop/pull/595/commits/bdf5919888bf061550d79483400cb12d87604817)
    • Luxon (https://github.com/hop-protocol/hop/security/dependabot/509)
    • Vite (https://github.com/hop-protocol/hop/security/dependabot/497)
  • Unused (https://github.com/hop-protocol/hop/pull/595/commits/d2380f64e308bd8b7348db5ae869a5e2610a5eec)

I was relatively against Husky because I didn't understand what problem it solved. I see now that it adds the ability to check stuff at the git hook level on the local machine, something I didn't realize was possible. Because of how small the API is and how lightweight it is (1.1kb - LICENCE is the largest file in the repo), I've warmed up to using it a bit. Two places where I see value:

• (IMPLEMENTED) Enforce not using .npmignore in favor of .gitignore.
• Lint code locally prior to push instead of CI failing after ~1 minute.
  • This seems nice in theory but might be annoying in practice, up for anything
  • We achieve this in some packages by adding to some of the NPM scripts. This seems slightly nicer, but this is a personal opinion.