Code Quality Tools for 3.2.0 and beyond

[jankapunkt]

The next release 3.1.0 has gained momentum and it already contains lots of changes.

At the same time I found, that there is no linter / formatter integrated. This is mostly, because lots of the code wasn't even ready to be linted until recently (for example, see #488).

Finally, there is a discussion in the community about code standardization for the Meteor Core. I think this is the right time for us to discuss, which code quality tool we want to use.

While I personally prefer biome for its opinionated out-of-the-box style, I also like the idea to be par with the Meteor Core codebase tools (which seems to be OXC).

Next steps

While release 3.1.0 is still in the works, we should use the momentum and decide for a code quality tool, which will be integrated into the codebase for our next release 3.2.0, for which development will start right after 3.1.0 has the first alpha release out.

Again, while I personally prefer Biome, I think we should go with the decision for Meteor Core.

[jankapunkt]

As per comment from @italojs this will be OXC. I therefore think its good to collect first proof of concept studies to see how well OXC can be integrated into our project structure (repo, config files, test-app, CI etc.) without breaking things.

Most important questions to answer:

• Can we integrate OXC without breaking the current repo structure (no top-level package.json; using test-app for testing as proxy-project; no multiple package.json files in multiple places, CI integration, npm script integration)
• Can we configure the Oxlint and Oxformat in a way that it will accept current excotic statements (such as global variables) so we remain 100% backwards compatible for minor releases?
• Can we make sure to set up these tools for development in one command (for example as part of npm install)?

[italojs]

Answers to Your Questions

1. Can we integrate without breaking the repo structure?

I think so, it's pretty configurable, more than Biome IM

2. Can we accept the exotic Meteor statements and remain backwards-compatible?

Oxlint has full support for this via the globals and env configuration - docs

// .oxlintrc.json — what I imagine from a globals section
{
  "globals": {
    // Meteor build system globals (package.js files)
    "Package": "readonly",
    "Npm": "readonly",
    
    // Meteor runtime globals
    "Meteor": "writable",
    "Tracker": "writable",
    "check": "readonly",
    "Match": "readonly",
    "ReactiveVar": "writable",
    "EJSON": "readonly",
    
    // Blaze package-exported globals (written as bare assignments)
    "Blaze": "writable",
    "UI": "writable",
    "Handlebars": "writable",
    "Template": "writable",
    "Spacebars": "writable",
    "SpacebarsCompiler": "writable",
    "BlazeTools": "writable",
    "HTMLTools": "writable",
    "ObserveSequence": "writable",
    "AttributeHandler": "writable",
    "ElementAttributesUpdater": "writable",
    "CachingHtmlCompiler": "writable"
  }
}

Additionally, we can use overrides to apply different rules for package.js files vs regular source files, and relax rules for test files (*_tests.js).

For oxfmt, it's purely a formatter that does not change semantics. It won't touch global variable assignments or exotic patterns. It just makes the formatting consistent.

3. Can setup happen in one command?

Do you mean a cmd in the pkg.json scripts? take a look in this PR, i imagine something similar for blaze

[jankapunkt]

Thanks a lot for the input @italojs this will greatly help and I also marked this as good first issue in case some first time contributors want to make their first commits 🙂