search

Meteor-Community-Packages / meteor-roles

Authorization package for Meteor, compatible with built-in accounts packages
http://meteor-community-packages.github.io/meteor-roles/
MIT License
920 stars 164 forks source link

Ideas for a v4.0 #295

Open SimonSimCity opened 4 years ago

SimonSimCity commented 4 years ago

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 commented 4 years ago

I would suggest we just keep iterating on v3 with those changes.

SimonSimCity commented 4 years ago

@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.

mitar commented 4 years ago

True.

StorytellerCZ commented 3 years ago

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.

StorytellerCZ commented 3 years ago

Besides that we should use ecmascript through the package if we have it as one of the dependencies.

StorytellerCZ commented 2 years ago

Ideas

Clovel commented 2 years ago

How about some TypeScript declarations ?

StorytellerCZ commented 2 years ago

@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 commented 1 year ago

What about making it an npm package to be used in any NodeJS project? Just like AccountsJS

StorytellerCZ commented 1 year ago

@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.

danyhiol commented 1 year ago

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.