URGENT: matb33:collection-hooks not compatible with Meteor 3.3.1

[mcorbelli]

Describe the bug
After upgrading to Meteor 3.3.1, the matb33:collection-hooks library no longer works as expected. Using hooks on a collection results in the following error:

TypeError: Cannot read properties of undefined (reading 'insert')

To Reproduce
Steps to reproduce the behavior:

1. Create a new collection with matb33:collection-hooks and idGeneration: "MONGO".
2. Add a before.insert hook, e.g.:

class AggregatedOrdersCollection extends Mongo.Collection {
  constructor(name, options) {
    super(name, options);
  }

  findOneByAggregateId = async (aggregate_id) => {}
}

const AggregatedOrdersDB = new AggregatedOrdersCollection(Collections.AGGREGATED_ORDERS, {
  idGeneration: "MONGO",
});

AggregatedOrdersDB.before.insert((user_id, doc) => {
  const now = dayjs().toDate();

  doc["dates"] = {
    created_at: now,
    updated_at: now,
  };
});

3. See the error in the console.

Expected behavior
The before.insert hook should be called correctly, allowing modification of the document before insertion.

Screenshots

Additional context
It seems the issue may be caused by the updated Mongo driver in Meteor 3.3.1. The library might require an update to be compatible with the new mongo module.

[github-actions]

Thank you for submitting this issue!

We, the Members of Meteor Community Packages take every issue seriously.
Our goal is to provide long-term lifecycles for packages and keep up
with the newest changes in Meteor and the overall NodeJs/JavaScript ecosystem.

However, we contribute to these packages mostly in our free time.
Therefore, we can't guarantee you issues to be solved within certain time.

If you think this issue is trivial to solve, don't hesitate to submit
a pull request, too! We will accompany you in the process with reviews and hints
on how to get development set up.

Please also consider sponsoring the maintainers of the package.
If you don't know who is currently maintaining this package, just leave a comment
and we'll let you know.

[mcorbelli]

@StorytellerCZ Do you have any advice on how to try to solve the issue? I saw that you worked on the library.

[vparpoil]

Which version of Meteor were you using before upgrading ? Which version of the package is causing the issue ?

[mcorbelli]

We upgraded from version 3.1.2 to 3.3.1. According to the changelog, there are quite a few changes, starting with the Modern Transpiler. As for the package version, we are using 2.0.0.

[vparpoil]

can you share a minimal repo with reproduction of your error ?

[jnoksoko]

We have the same issue with Meteor 3.3.2 (upgrading from 2.16). Tried also 2.1.0-beta.3 version with no luck.

[evolross]

Our production app uses Meteor 3.3.2 and I can confirm that matb33:collection-hooks@2.0.0 works with it (also in Meteor 3.3.1).

The only weirdness we ran into is that some simple-schema functionality quit working when using the direct version of some hooks. And we were able to add patches for those.

Overall we've found matb33:collection-hooks to be a problematic package, but it does still work. I'm happy to help you troubleshoot.

[harryadel]

@evolross Out of curiosity since I've worked on collection-hooks? What're your pain points with it? I'd greatly appreciate if you can be verbose, thanks!

[evolross]

Here are a few:

• In the last few versions of Meteor it no longer works correctly with collection2 or simple-schema. Though this could be due to those packages. In general though, with each new version of Meteor it seems the package gets more touchy.
• The fact that in Collection.after.update hooks the doc isn't updated proves to be problematic in a lot of patterns. We end up having to rely on the modifier to figure out what happened, which works most of the time but there's some scenarios where it doesn't. It would be nice if the after hook truly ran after the document was updated and returned the updated document, instead of having to query for it when checking the modifier doesn't work (an example of this would be an $inc - that doesn't give you the value in the modifier).
• Hooks always run "per document" which can make the entire package useless for many bulk-type updates where you need the action of the hook to run for multiple affected documents but don't want the inefficiency of having a hook run 1000 times, for example (especially if a query is involved in the hook). So you end up writing the same code twice - once in a hook for single document operations and then again in bulk-type operations. We're finding it easier to avoid hooks and just write regular code that works for one-to-many, not inside a hook.
• We leaned heavily into Collection Hooks for a lot of functionality early in our app and didn't use much import/export of functions, because it's just "easy" to write a hook that cleans up everything, etc., and it seems like this ends up causing a ton of overhead. Especially when you need to query other Collections within hook. You could end up querying the same document 3 or 4 times in the process of a single operation. For example, you query some secondary Collection's document for a Meteor Method's privilege validation, then you need that secondary document in a before hook, then again in an after hook, etc. It just becomes way more efficient to write reusable functions you can import into Meteor Methods, etc., to do repeatable functionality versus writing stuff in hooks. It makes more sense to just query for a secondary Collection's document once at the top of the code, then import reusable functions. Stuff like this matters when running at scale load.
• We've had other problems with the direct modifier where once you're in a direct operation's closure you can't get back out of a direct closure in a lower callback, meaning you can't trigger hooks. There are undocumented tricks we learned in how to deal with this, but overall it always requires a lot of brain power to remember.

Some of the above is early inexperience with Node.js, JavaScript, etc. But overall, our app unfortunately has to have the collection-hooks package working correctly or the whole thing would come grinding to a halt. We use it for a ton of denormalization and cleanup of denormalization. So I can assure you, the package is working with the latest Meteor.

Overall, we're slowly getting rid of it which is in turn making our code more optimal. We may have to use it in a few places, but it will ideally be very minimally.

[harryadel]

Thank you, this is so in-depth. I was wondering about the viability of this package and it seems to be very viable even with all of these issues. If given enough love this package can be a turned around but sadly so many people aren't willing to chip in [I'm not pointing fingers but this is the nature of the matter]

I hope with #320 to at least set the needed infrastructure for future work. Can give this beta a test and tell me if it breaks anything in your app?