admin
admin copied to clipboard
nodejs
Publishing @nodejs/i18n under `@nodejs` scope on npm
Currently the @nodejs/i18n team has been working on making the translated docs into a module. Currently, it's only consumable via git installs. There's currently an open issue requesting to publish it as @nodejs/i18n on npm: https://github.com/nodejs/i18n/issues/328
How can we make this happen? 😇
going through old issues and wanted to follow up here. Since previous pings didn't work, going to ping the two top-level committees: @nodejs/tsc @nodejs/community-committee. How can we get this published to help lower the barrier to entry for i18n?
~In theory we need to ping TSC and CommComm, so that's a good start :)~ I might've mistaken the npm policy with repo creation policy 😅
I'm generally +1 if no one objects with starting to publish on the Node.js scope (I know there's a bit of history on this topic and this would be our first package). We just need to find out who own the nodejs scope and preferably ask them to add TSC and CommComm members there as well transfer ownership to the nodejs-foundation account.
We are reserving the nodejs scope for internal /core usage. I'm -1 for using it for external usage.
@bnb I don't think we have any, but we could probably create one. Some ideas:
- nodejs-contrib
- nodejs-misc
- nodejs-utils
- nodejs-packages
We are reserving the nodejs scope for internal /core usage. I'm -1 for using it for external usage.
What's the definition of internal vs external? Whether or not it depends on core internals through process.binding? Or whether or not it is intended for possible future inclusion into core?
@nodejs is kept for core to use internally. Essentially the module loaded with the @nodejs scope would be loaded from the binary.
@mcollina the built in modules spec is moving forward with using : as the delimiter not @. Does that change your opinion at all?
FTR I think that we should consider something like nodejs-extras@ anyways, as labelling something @nodejs does give it an unfair ecosystem advantage and potentially the impression that it is officially blessed. That could cause us to raise the bar a bit higher than necessary to include things in the scope.
I could see us using @nodejs for publishing polyfills or externally consumable / compliant versions of our APIs
I'm representing only the historical view of the problem. If we want to use if for other purposes.. it's ok for me.
does give it an unfair ecosystem advantage and potentially the impression that it is officially blessed
Isn't this already the situation with the project on the GitHub organization? Also isn't that the point of having it on the org? I'm confused on how this would be different?
as labelling something @nodejs does give it an unfair ecosystem advantage and potentially the impression that it is officially blessed.
FWIW this isn't intended to be an ecosystem thing, this is for our own translations of our own documentation.
ohh, I definitely misunderstood that before. In this case I'm -1 on using @nodejs as it can give the false impression for external users that the package is intended for them. I do think having a scope for internal tooling is a good idea, maybe something like @nodejs-internal or @nodejs-dev/@nodejs-development (@nodejs-tools also seems like it would be an external-facing scope).
OTOH other projects like Electron do publish tools intended for the project on @electron instead of a different scope: https://github.com/electron/build-tools
maybe something like @nodejs-internal
Plus one to this. I know if I saw a package which looked useful on the @nodejs npm org I would not hesitate at all to tightly couple to it. @nodejs-internal on the other hand would make me think twice and reach out to the maintainers to ensure that was alright.
EDIT: Also, for tools and packages generally useful to the community, we have the @pkgjs org. We are playing it much more loose there, but some of what @electron use their scope for is how I see Node using the @pkgjs. Tooling not tightly coupled to Node but maintained by folks with strong alignment.
Personally I do not like the name @nodejs-internal but can't think of anything better, so can't really recommend a different one 😅
No real opinion on the scope, but I think maybe adjusting the name to something like node-api-docs might relieve some of the concerns around promotion
I didn't mean to say I was tied to the -internal, just that the bare name implies external use is ok to me. Perfectly fine with any other naming scheme for "things not intended for external use".
My vote would be for @nodejs/i18n if we can make it happen.
While the primary consumer of a @nodejs/i18n (or similarly named) package would be the Node.js website (i.e. an "internal" user), the package could also have potential value for the "external" ecosystem of Node.js users as well. The would be anyone who wants to consume structured Node.js documentation in multiple languages and for multiple Node.js versions.
In my previous comments I was focused on the scope name, but to give feedback now that I see the package base name is also for discussion 😄...
I would not expect the translations of the docs to be called i18n. To me that would be a package for doing i18n in node, or to support nodes runtime i18n capabilities. I would think docs which contained all the translations would be the name I expect (so full package name as @nodejs/docs). This is completely armchair feedback though as I have not been involved at all, so feel free to ignore me (also I am literally sitting in a reclining armchair).
Creating a scope for a single module seems strange to me.
We could use the @nodejs-extras that could be useful on future projects.
+1 @nodejs-extras/docs
The more I think on this, I am strongly in favor of using @nodejs as the scope for public consumption of node packages. I especially like the idea of being able to npm i @nodejs/docs and have a local copy. I think it is reasonable to have both internally used packages and public use packages in the same scope. If the idea is to reserve one scope for internal only packages, I think it should not be @nodejs and instead be one with less branding value.
@wesleytodd by internal packages do you mean like shims for Node.js APIs (like readable-streams), or packages that are only relevant to the project (like node-core-utils)?
I think the distinction I wanted to make was about the perception of "should I, a random dev, use this package?". When @mcollina said above that it was going to be used for "internal/core usage" I wanted to point out that the scope @nodejs would mean the opposite for me.
by internal packages do you mean like shims for Node.js APIs (like readable-streams), or packages that are only relevant to the project (like node-core-utils)?
In the last comment I think I mean node-core-utils not readable-stream. readable-stream is used all over the place, and is the exact kind of package I would see published in the @nodejs scope so that folks can find packages maintained by core, but not in core. Similarly, I see publishing the docs as something good for public use, so in @nodejs.
FWIW I generally agree with @wesleytodd's expressed perspectives here but it's also a hill that I realize I do not have enough of a stake in to meaningfully drive consensus on 😅