rewrite in js except parsing that uses oxc with meriyah as fallback

[rochdev]

Rewrite in JS except parsing that uses OXC with Meriyah as fallback.

Upcoming RFC will explain the rationale

A few features were also carried over from the original iteration of the rewrite:

• Supports an astQuery field to filter AST nodes with an esquery query. This
  is mostly meant to be used when experimenting or if what needs to be queried
  is not a function.
• Supports replacing methods of child class instances in the base constructor.
• Supports tracing iterator (sync/async) returning functions (sync/async).

[jsumners-nr]

I haven't reviewed any of the functionality at this time. Just some maintenance type suggestions.

I'd like to see jsdoc blocks on all functions, classes, and methods. This will reduce the need to follow all paths to understand what shapes parameters are meant to be and clarify intentions.

[jsumners-nr]

Please omit this file.

[rochdev]

It was already there (which is why I also used yarn for CI). If this is not expected it should be removed outside the scope of this PR.

[rochdev]

I switched to npm for commands but kept the lockfile since it's already there. I will either open a follow up PR to switch back to npm lockfile, or just remove it along with all the Rust.

[jsumners-nr]

I don't see the point in any lock file in this project. They will just be ignored by any package manager when the module is installed.

[rochdev]

The point is deterministic builds. For example, if a new version of a dependency is released which has a bug, CI on the main branch (and all branches) will start failing, blocking any work on the library. It's better to have that happen in an isolated branch, for example a daily update by Dependabot.

[jsumners-nr]

I disagree. If we want "deterministic builds" then we shouldn't be using semver ranges, but instead specific version numbers for dependencies. My opinion is that semver ranges should be kept, and bugs resolved issues resolved as they are discovered due to no lock file being present. When semver ranges and lock files are used in conjunction, no one ever knows when a problem has been introduced that will break users because the module being developed is really using semver ranges, whereas the users of the module are using the ranges.

[rochdev]

If we want "deterministic builds" then we shouldn't be using semver ranges, but instead specific version numbers for dependencies.

Specific version numbers don't work for issues in transitive dependencies. I don't have a strong opinion either way for this project, just stating the trade-offs. For a small project like this it shouldn't matter much, but in larger projects I can say from experience issues can arise pretty much weekly and sometimes even daily. But in this case I would expect maybe a few per year so not the end of the world.

bugs resolved issues resolved as they are discovered

Agreed, which is why I mentioned a daily Dependabot. There is nothing worse than having all PRs blocked until someone gets to fixing the main branch. But again, less of a problem in a project that doesn't get dozens of PRs per day 😄

[jsumners-nr]

I'll leave this thread off with: Dependabot is a solution in search of a problem. I literally ignore every notification from it.

[rochdev]

cc @timfish as the lockfile was added in 288764e

Since the project seems to otherwise use npm, this may have been a mistake. If it was, happy to just remove it in this PR.

[timfish]

I probably added it without thinking much because in general most of the repositories I work on commit the lock file and most of those repositories use yarn. This can be removed!

I personally do prefer having a lock file because it removes a some of the supply chain risk of not having one at all.

[jsumners-nr]

Let's please use the standard package manager: npm.

[rochdev]

I did at first but then noticed the project uses Yarn.

[rochdev]

Switched back to npm although that means CI is no longer deterministic until the lockfile is also changed.

[jsumners-nr]

We have inconsistencies here:

1. Double quotes in this directive, but single quotes in the lib/compiler.js directive
2. Explicit semi-colon here, but not on line 3 (or in lib/compiler.js)

Let's solve these sort of issues by utilizing neostandard:

npm i -D eslint neostandard
npx neostandard > eslint.config.js

"scripts": {
	"lint": "eslint .",
	"lint:fix": "eslint --fix ."
}

[rochdev]

I was a bit surprised by the lack of a linter but I guess the project didn't have much JS so it makes sense. Will look into neostandard.

[rochdev]

Added neostandard and fixed all issues. I ignored the tests folder for now since it has 1000+ issues that were already present.