Hyperapp: Hyperapp Community Projects

[jorgebucaran]

For current and new npm modules: Do we want to publish them as @hyperapp/gizmo scoped packages or regular hyperapp-gizmo prefixed packages?

---

tl;dr

1. Got a cool idea for a module that depends on Hyperapp or extends Hyperapp's functionality, e.g., a higher order app, a utility library, a helper function? Use this simple template to get started and publish it on npm as hyperapp-foo.

2. Think your module is relevant to be published as an "official" @hyperapp/foo scoped package? Create an issue on this repository or let us know on Slack and we'll take it into consideration. If it's approved, you'll be invited to the Hyperapp organization on GitHub and npm so you can take care of your module.

That's all folks! 👋

[Siilwyn]

Babel is also looking to use scoped packages, might be worth looking how & if they pick it up: https://babeljs.io/blog/2017/09/12/planning-for-7.0#using-npm-scoped-packages

[jorgebucaran]

Whatever path we choose, I hope most of those repos & projects can live under the new HyperappCommunity organization.

See

[frenzzy]

I think we should not publish community projects under @hyperapp scope while we do not have naming collisions between repo owners. And it also less work for both @hyperapp npm scope owner and repo owner. I would reserve @scope for possible future official packages.

By the way babel introduced @scope to not collide with community driven packages.

[whaaaley]

Scopes!!!

I like being able to do a quick poke into node_modules to see what kind of stuff is being used.

[SkaterDad]

I like the idea of using the @hyperapp/ scope for HyperappCommunity packages, but who manages the publishing rights?

[jorgebucaran]

@SkaterDad Yes, that's the other issue. It's more work. I wouldn't mind inviting more people to the npm org (we have like 4 or 5 people currently there already).

[okwolf]

Looks like we're using the @hyperapp/* packages now: https://www.npmjs.com/package/@hyperapp/transitions

Perhaps that should only be for projects in this org and not https://github.com/HyperappCommunity though.

[jorgebucaran]

Let's make it worth it! Only the creme de la creme. 🍨

[zaceno]

@okwolf @JorgeBucaran Didn't mean to claim that transitions is creme-de-la-creme 😉 Sorry if I jumped the gun on this! -- I plead confusion from the many moves and directives that came in a short period of time. The reasons I did it:

• It bugged me to have hyperapp in the repo name since it's already under (the very long) HyperappCommunity. So I changed the name. And I like my packages named same as the repo.

• Some packages in the community org are already doing it that way (html, router et al). Moving them to the community in a way sets a standard for how repos should be named and published. (Unless we plan to name them hyperapp-router et c)

• From here and slack I got the impression that the majority consensus, although not unanimous, is in favor of @-scoped packages.

... so it seemed the natural next step. But don't worry -- I can go back to publishing under the name hyperapp-transitions no problem :)

(And I'll hold off renaming my other packages awaiting further comments)

[zaceno]

@JorgeBucaran I think there should be a standard among community packages -- or the community will look very messy. Perhaps the "creme-de-la-creme"-criterion should be a bar for being moved into community? (I say that realizing that some/all of my packages might be moved back out if that's how we decide)

[jorgebucaran]

@zaceno The three defining moments in the life of a Hyperapp Gizmo.

1. github.com/username/hyperapp-gizmo → npm i hyperapp-gizmo
   ~2. github.com/HyperappCommunity/hyperapp-gizmo → npm i hyperapp-gizmo~
2. github.com/hyperapp/gizmo → npm i @hyperapp/gizmo

Skip 2. It's 1 and then 3 someday (maybe and if the author is willing, of course).

Every gizmo starts somewhere. Usually at github.com/username/gizmo. Ratified "useful" modules, those that have some community interest and are well groomed, can be promoted to HyperappCommunity if the author wants to. Just ask!

For a gizmo to go @hyperapp/gizmo, then it must definitely be _The Gizmo_ and their author must show clear intent to maintain it and keep it in good condition.

---

Now, you can skip 2 and go straight to 3 from 1. There's no rule saying that every module needs to go through HyperappCommunity to become a scoped module. In fact, some people may even prefer to keep their modules under their username and that's perfectly fine.

[zaceno]

@JorgeBucaran 👍 good structure!

As you know, at first I advocated only a single org, but I see now that comes with ownership/curation issues. This structure is good.

[jorgebucaran]

@zaceno To be honest, right now I would prefer to go back to:

(1) and then (3) if the module gets to that level. But I had to write that up because, after all, I am the one who is responsible for the whole mess of creating a new org, then moving packages around and now back to square one. 😅

[zaceno]

Makes sense too. I wouldn't mind moving my packages back to zaceno/gizmo. There's always the awesome-list to get exposure. Except ... as long as there is a HyperappCommunity, I think that's where I want my packages, just not to give the impression that they're somehow experimental (unless they are ;) )

But if you decide to shut it down and have everyone move their packages back, that's fine with me!

EDIT. Actually... no, now that I think of it, I think I too would prefer to move my community-owned packages back home to zaceno regardless. So I will.

[jorgebucaran]

@zaceno Well done. I went ahead and deleted it. Now it's only github.com/hyperapp and that's it.

Looking for this issue's tl;dr? See above.