Add an OpenAPI middleware to the org

[wesleytodd]

I was wondering what people think about adding middleware like this to this org?

I built this because of a need I had, but it is similar to something that Fastify supports directly, so I thought it would be good if express had one as well. I haven't published it yet, and I was thinking that if we liked it we could publish under the @express scope.

I would also love feedback on the module itself. It is still a work in progress, but if anyone sees any glaring problems, or better api I could adopt, I would like to hear it.

[wesleytodd]

I would like to get this published soon. @dougwilson How do you feel about publishing this kind of module under the @express scope, and if you like it can you give me publish rights?

[dougwilson]

Sorry I have been away and haven't had time to put all my ideas here but (1) the pillarjs org is not really the correct org for express middleware (2) it feels weird to add more modules to the org when there are still module languishing and need to either get support or get removed instead of spreading even thinner and (3) idk much about the scopes / how exactly they work / what giving publish rights in the scope means.

[dougwilson]

P.S. I like the interface you made for that module

[dougwilson]

Apart from the scope question, if you feel really strongly about adding it to the expressjs org (which seems like the correct place for an express middleware), you're welcome to do it. Ideally the repo name should match the npm module name exactly. I think the ones that are published as "express-blah" are just named "blah" in the org, though, so that is acceptable.

Ideally as well the readme would blend in with the rest, like how the badges are and stuff, to make them seem like they are somewhat coherent.

Is publishing as express-openapi a solution for the module name? If not, what does the scope thing entail? I have thought about using scopes before, but that was after everything was already made, so I thought it would feel very weird if somethings where under scopes but not others. But npm also provides no mechanism to migrate an existing module into a scope as far as I know, so it would effectively be a brand new module with no history and no update alerts to previous users, so just kind of never felt good about trying to move to them.

[wesleytodd]

No worries, sorry to demand attention like I did :)

(1) the pillarjs org is not really the correct org for express middleware

Ok, seems reasonable to me. I guess there are two options:

1. Use the express org
2. Let it live in under my name

We could still publish under the npm scope with any of the options. We can even make this decision later.

(2) it feels weird to add more modules to the org when there are still module languishing and need to either get support or get removed instead of spreading even thinner

Agreed. I intend to support this as it is something I need at work. The goal of making it "blessed" in this way is more so that we can keep up with the good features other projects are adopting. It's more as a vanity thing for the project to have it under the core name than anything about the feature or

(3) idk much about the scopes / how exactly they work / what giving publish rights in the scope means

I think if you add me as a member it would mean I can publish new packages in the scope. After that I think it is still per-package permissions like any other package. If you are interested in the docs:

https://docs.npmjs.com/orgs/

[wesleytodd]

P.S. I like the interface you made for that module

Thanks! Any improvements or feedback is continually welcome!

which seems like the correct place for an express middleware

Ok, I don't feel strongly, but I do think it is good for the core project to lend some validity to certain types of modules (like session and body-parser for example). It is one of the reasons people like other ecosystems where things come more "batteries included". Not to say we should over index on that.

Ideally the repo name should match the npm module name exactly

Ideally as well the readme would blend in with the rest

Agreed.

Is publishing as express-openapi a solution for the module name?

No, that is already taken.

If not, what does the scope thing entail?

The whole point of scopes it to allow more control for communities to name their packages. So by using @express we could name things appropriately under that scope. The rest is just permissions and any organization decisions we make.

I think having some under the scope and some not is fine. I think ideally we would migrate toward using the scope, but the churn of moving existing packages is nor worth it. We could say "all new modules are under the scope", if we wanted. As I said, mainly it opens organization and naming control by not having to compete with the global namespace. Other than that it should not have repercussions.

The babel community migrated to their scope recently and IMO it was a big churn with no real benefit. It caused a ton of problems for uses who then opened issues all over the place. Best avoided if we can.

[dougwilson]

So back on the scope thing, thanks for the link. The name express is used already. If we feel strongly about that name, we'll have to start a conversation with npm, inc. and determine why it's taken and how we could get it. It's hard to know if that's even going to be possible since we have no legal marks on the word "express" so there is no real leverage here.

[wesleytodd]

Oh for some reason I thought you had said that you had it. I must have miss-remembered.

I do think it would be reasonable for us to claim that from npm, and for them to give it to us becaues there are no packages published under that scope at the moment. I can reach out to npm and get that discussion started and cc you on the email.

[dougwilson]

Sure. I still feel we should not publish this under a scope anyhow. I think that once we introduce scopes, all the middleware not in a scope will appear to many people as not official. I see it's how a lot of npm devs I interact with feel about seeing a scope that it's like an official badge thing. Especially if they don't use scopes themselves.

[dougwilson]

If we really really really want a scope, perhaps we should have this discussion in the expressjs org and invite the other express members to participate in the conversation? Having this in pillarjs org seems like the wrong place to talk about express middleware, as that is the separation of the orgs in the first place :)

[wesleytodd]

Ok, I agree opening the conversation to a broader audience would be great. TBQH the reason I opened it here is that this middleware couples more to router than to express directly. That probably doens't have consequences on the scope discussion, but it might for where this particular module ends up.

I will write up a synopsis of the scope conversation and post it to the express discussion board, as well as start the email to npm so that we have the option if we decide to take it. Either way we should prevent some other group from using @express if we don't decide to use it.

[dougwilson]

TBQH the reason I opened it here is that this middleware couples more to router than to express directly

Actually, didn't really think of that. I think that since you were prefixing it with the suggested @express scope, I didn't even think into it much, because that seems to me to directly tie it to Express directly. If the desire is not to make it explicitly express, it probably doesn't make sense to put under the @express scope anyhow.

Looking at the source code it also uses things like req.app which is specific to Express and cannot be used with the router module unless Express is used, which re-enforced my perception that this is an express middleware specifically. I hope that makes sense.

Either way we should prevent some other group from using @express if we don't decide to use it.

I believe this is against the npm TOS: it would fall under squatting, right?

I'm looking in https://www.npmjs.com/policies/open-source-terms#acceptable-use

A few examples of unacceptable content: [...] Content that exists only to "reserve" a name, whether a package name, user name, or organization name. The Dispute Policy governs how npm handles such cases of "squatting".

[wesleytodd]

Looking at the source code it also uses things like req.app which is specific to Express

Doh, right, forgot that I added that. It was not in my original POC code.

I believe this is against the npm TOS: it would fall under squatting, right?

Is it squatting if it prevented someone from using it to push malicious code under the guise of the express name? That is really what I would want to prevent by "squatting" on it. And I would think npm would agree.

[dougwilson]

Is it squatting if it prevented someone from using it to push malicious code under the guise of the express name? That is really what I would want to prevent by "squatting" on it. And I would think npm would agree.

I get where you are coming from. I just don't want to violate a rule and get other issues fi we didn't need to have done that in the first place. Publishing as a name such that express-next can be used in the same way to social engineer folks to think it's a real thing (in this case, it could be a preview of next gen express features). Similar to publishing malicious code at express-cors or express-render or whatever you want :)

Moving everything of ours into a scope 100% would be the way to combat that, because then official vs not can actually be distinguished by name, which is how a lot of devs act that I have spoken to. It can still be spoofed by having a similar scope like @express-node, but if all of our things are all 100% in a scope, a typical package.json will make this more obvious, similar to how devs I talk about @angular feel about their package.json file.

I've seen some . go out of their way to use things that start with @angular over ones that don't, even if the other was better, which also sadly seems to have the slight effect of the community not being able to freely complete / compliment "core" modules as they feel inferior to folks just by the name itself. But maybe that could attract more "core" contributors, idk, haha.