meteor-roles
meteor-roles copied to clipboard
Meteor-Community-Packages
Ideas for a v4.0
My goal for the next major version, which will be v4, is to move everything out of the Meteor object and do everything to have this package doing nothing if you do not import it and execute some methods.
This will make this package ready to take advantage of tree-shaking 🌲
@mitar Well, it is a backwards incompatible change - not in terms of the database structure but for the programmer using it. If I keep the version numbering strongly on the semantic versioning model, this is a major change.
I think this major change is enough for v4. Anything more is not necessary. If people are using imports properly it won't be as crazy change as we had in the last two releases. I think adding any functionality should be for v4.1+, unless it is a new breaking existing functionality.
Besides that we should use ecmascript through the package if we have it as one of the dependencies.
Ideas
- Stop adding roles collection to Meteor object. Instead export them.
- Modernize
package.jsto usemainModule, etc.
@Clovel yes, that needs to happen. Let's do a full rewrite into TypeScript. This is the sort of package that should have it.
@danyhiol possible spin of, but the issue is that we are closely integrated with MongoDB, so that would be a major undertaking to make that modular. Also we'll have to check into integration with other Meteor specific parts like the accounts system.
but the issue is that we are closely integrated with MongoDB
One solution would be to abstract the DB layer with default to MongoDB. And then incrementally add support when needed for other DB. But I do agree that may be complicated.
integration with other Meteor specific parts like the accounts system
This one may be tough but there would be no other way than abstraction/modularization.