Skip to content

Start work on collection:<name> packages #72

Open
@zimme

Description

@zimme

Hey

I've been working with my packages lately and this got me thinking I wanna start renaming some of my packages and I thought about using the collection namespace.

@dandv: Would you mind adding me to the colllection organization as I saw that you were one of the maintainers of it.

This is what I have in mind for my own packages:

  • zimme:collection-behaviours -> collection:behaviours
  • zimme:collection-timestampable -> collection:timestamp
  • zimme:collection-softremovable -> collection:softremove

My upcoming work for archiving docs would go into collection:archive.

I would also like to ask a couple of the other guys if they're willing to join my effort and provide their functionality under the collectiton namespace.

@rclai
lai:collection-extensions -> collection:extensions?
Maybe even collection:core? (this needs more discussion)

@mattb33
matb33:collection-hooks -> collection:hooks?

@dburles
dburles:collection-helpers -> collection:helpers?
dburles:mongo-collection-instances -> collection:instances?

My thoughts around this is that we all try and rely on each others work as much as possible.

I know @dburles already accepted a PR to use lai:collection-extensions, which is nice.
I've also seen @lai doing some work on making @matb33's matb33:collection-hooks rely on lai:collection-extensions.

I myself would rely on his package for collection:behaviours to have the option to automatically add the behaviours to all the collections instead of just manually attaching the behaviours to specific collections, but I feel it should be a choice. There will be a need for supporting an exception list though.
In my packages for specific behaviours like collection:softremove I already rely on matb33:collection-hooks.

We would all be responsible for our own packages under the namespace, but I believe the benefits of us all working more close together are great.

We would make the decision on which "new" packages we would accept into the namespace.

Examples:

  • Once i start working on collection:archive I wouldn't publish the work under the namespace until a majority of us feels its ok to do so.
  • If we get requests from package maintainers to join the namespace we would make that decision together.

I also think we could work out of either the MeteorCommunity or MeteorPackaging organization on Github.
Another alternative is to use one of MeteorCollection, MeteorCollections or MeteorCollective organization which I've just registered. I will remove the unused organizations once a decision has been made.

Who knows, maybe @aldeed want to join us with his aldeed:collection2 package under the name
collection:validation or something in that direction.

I feel that we all could benefit from such an endeavour.

What do you guys think? Do you feel it's worth it?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions