npm module name / Node.js built-in worker module

[addaleax]

Hi there!

I’m currently working on built-in Worker support (as in, threaded workers rather than cluster/child process) in Node.js, and there is only little left to do for that. (It’s basically just porting over changes from a fork of Node, Ayo.)

Now, the most natural way to expose that functionality seems through a built-in worker module. Since you own that name on npm, and your module would thus conflict with this: Would you be willing to rename/move this to another module name (similar to what we did for http2)? I realize it’s a pretty great name to get, but on the other hand I’d like to a natural name for the built-in module.

Let me know if you have any thoughts/questions about this!

[blake-regalia]

Hi Anna, I understand the desire for a nice npm name, but I only recently just acquired this name from another owner. More importantly, my project is still very active. Not only does it target node.js worker child processes via IPC but it also abstracts WebWorker in the browser, which was also a condition that the previous owner considered when surrendering the name over. Sorry, but I would suggest using a scoped package name, finding a library that is dead / not maintained, or getting more creative with the name. Best of luck!

[benjamingr]

To be honest - I realize Anna is asking super nicely here but I don't see why we should take a 50 downloads/week package into account when considering clear naming for millions of users.

I think Node.js should focus on what's best for our users. I think it would be better to focus on how @blake-regalia can contribute (if they want) from their domain knowledge into Node.js workers and help shape them rather than this particular package.

Edit: I've added some motivation here: #1 (comment)

[kyleknighted]

@blake-regalia I hope you don't back down. This is your project. Your NPM name. If they want it, let them pay for it. You owe them nothing and you have something they want. I'm sorry a bunch of "adults", who act like spoiled children, want to come into your world and start harassing and bullying you.

I hope this blows over and doesn't dissuade you from continuing to contribute to the OSS community.

[pubkey]

I prefer a worker-module that works in browsers and node. Why not use require('node/worker') for native modules?

[addaleax]

Everybody relax :) I asked @blake-regalia to provide the name, not to give it up because we’re the larger project. It’s not something anybody forces him to do.

@kyleknighted I have no idea where you get any of that from.

Why not use require('node/worker') for native modules?

There has been a lot of discussion on this topic.

[dy]

@kyleknighted I wonder why do you think npm community should be so much monetary self-profit driven? Isn’t freeing name for a package that is worth a lot for millions already a reward? That is a chance to contribute to node core and good npm infrastructure development.

[kyleknighted]

@addaleax

No idea where I'd get such info...

[benjamingr]

@kyleknighted just to be clear I am absolutely under the impression Node.js should use the better name if at all possible and that Node.js should collaborate with the author of said module if at all possible.

I am not hiding that fact at all. Mainly because:

• If/when we ship a built in module I wouldn't want users to get confused and access a userland one which can be a security vulnerability.
• The module name is not originally this project's, according to the author it was acquired recently.
• The fact the module name changed recently is a good indication that the first point here is a possible issue.
• Node.js has started using this name for workers 3 years before the package in question here ever got the name (from another author).

Note that this is just my opinion and not Node.js's as a project, should we ever use the name it would have to be decided on at a project level - I am expressing my opinion as one person. People are free to disagree.

I am not trying to "strong arm" anyone, I am certainly not trying to dissuade anyone from participating in open source. I would love for the author of this package to participate more especially now when Node.js wants to ship workers because their information is valuable.

I am optimizing for one thing only here - the humans using Node.js, I personally don't see why millions of developers should get a worse name for a 47 downloads / week package that didn't even have that name for very long.

I am entitled to hold that opinion, I would appreciate it if people would respect that.

[benjamingr]

Also @kyleknighted, I think there is a miscommunication where Node.js might appear to be this big scary project. It's a bunch of people who are interested in Node.js and are working on it.

Working on it isn't barred from anyone, feedback is explicitly welcome and you are welcome to volunteer and participate like the rest of us.

In fact, if you're interested (and this goes out to anyone else reading this) - you are welcome to email me personally (my email is listed in https://github.com/nodejs/node) regarding being more involved with Node.js where you can help make these calls and I promise to do my best to help. I like having people who disagree with me (or others) around.

[kapv89]

My 2 cents, If the "threaded workers" that @addaleax is working on provide "shared-memory parallelism" for node.js, which in turn should technically provide the ability to use loaded modules across multiple threads in parallel, and the ability to work on shared data in multiple threads, then I think @blake-regalia should concede the package name. It'd be better for node.js, and for every professional and company that depends on node.js.

[benjamingr]

@kapv89

Where is everyone coming here from 😅? In my experience the more "new" traffic some place gets the more miscommunication and misconceptions there can be.

If at all possible - I would rather find that place is and then make ourselves available to answer their questions. The technical steering committee takes questions every week, everyone is welcome to open an issue and Node.js is trying to be very transparent and open.

If Node.js antagonised or alienated anyone that concerns me and I would prefer to figure it out. You are welcome to reach out to me (or the project) directly if you prefer.

[kapv89]

@benjamingr I saw this on twitter, Javascript daily tweeted it, I posted this discussion on reddit right now, cos I seriously think that shared-memory-parallelism is one of the few things that node.js really needs. Gonna take down the reddit post.
Update: took it down

[blake-regalia]

It seems to me that this approach of seizing a package name for each new internal module that comes along (and I'm sure there will be more in the future) is largely unsustainable. The real solution here should be the preventative and long-term measure of distinguishing between internal modules and public 'packages' in the call to require. If I surrendered the name then it would propagate a morally questionable precedent that I don't agree with.

@benjamingr I must add that I find it ironic that some leaders of a project which prides itself on fostering such an ideology is willing to take such an entitled stance on this matter.

I appreciate the discussion and hope it serves towards improving your project.

[dy]

If I surrendered the name then it would propagate a morally questionable precedent that I don't agree with.

As a matter of fact, many other people let go of their package/user names for benefit of everyone, personal examples are orca, audio-play, tst, audio, jsxify and others. In turn, scapjs is an org ready to give out any deprecated/unused packages there.

Morally - why holding a name knowing you won't be able to do that package as useful and good? That could be "collaborating" instead of "surrendering".

[ericandre615]

What about 'thread' or 'webworker' not sure those names are already taken.

[addaleax]

webworker doesn’t work because it’s not an implementation of web workers, it’s more powerful than that.

[ericandre615]

Yeah was suggesting that more for the current npm 'worker' package and 'thread' for this nodejs package. I mean it seems threads are the main thing here. I am seeing that word Every time I look at something for this.

const { Worker, isMainThread, postMessage, workerData } = require('thread');

Even has something called isMainThread, seems like a clear sign to me. Obviously the owner of this 'worker' package does not care to give up the name.

[benjamingr]

It seems to me that this approach of seizing a package name for each new internal module that comes along (and I'm sure there will be more in the future) is largely unsustainable.

Node.js doesn't plan to add a large number of modules though.

The real solution here should be the preventative and long-term measure of distinguishing between internal modules and public 'packages' in the call to require. If I surrendered the name then it would propagate a morally questionable precedent that I don't agree with.

So just to be clear - you are trying to educate the Node.js foundation and force their hand not because of the package name but because you believe in a different technical decision about how module naming should work?

@benjamingr I must add that I find it ironic that some leaders of a project which prides itself on fostering such an ideology is willing to take such an entitled stance on this matter.

What ideology? What entitlement?

Node.js does not need to consult package authors if we want to use names for internal modules - that's a promise we never made and the only measure I personally believe in is usefulness.

Moreover - Node.js doesn't actually need the package name in order to make a module internal - Node can decide to vote on it and take the name. People using npm install worker would still get this package but all require('worker')s would point to the internal module. require('./node_modules/worker/index') would still work though.

I think Node.js should do whatever is best to the humans using it (as explained here).

I appreciate the discussion and hope it serves towards improving your project.

Thanks, I hope this discussion isn't coming off as aggressive from my part - I am trying to be honest and upfront about my opinions here. I appreciate you taking the time to respond and share a different perspective.

It would also be great if you took a look at the workers PR at Node and tell us what you think :)

[kapouer]

There is absolutely no point in getting the npm worker package name.
https://www.npmjs.com/package/path
https://www.npmjs.com/package/util
...
so this whole discussion is just a flame.

[benjamingr]

so this whole discussion is just a flame.

I respectfully disagree - I certainly wouldn't want Node.js to take a module name without discussing it first internally and communicating it to the community and the author. I think Anna did the right thing opening this issue.

I haven't made up my mind yet (and neither did the Node.js foundation), I'm still learning from others' opinions and while I have an opinion it is not set in stone.

I'm learning from the discussion here - I wouldn't consider if flame - but maybe that's just me.

[MadaraUchiha]

If I had a time machine, I would have preferred Node modules to be prefixed, so node/fs, node/http and this newest addition, node/worker (or some such).

But this is not the case, and this it would be a major compatibility break to do so, while possible, very undesirable.

Now, it's worth noting that Node has the power to simply take the name, and leave this package in the dark. Quoting @benjamingr:

Node.js doesn't actually need the package name in order to make a module internal - Node can decide to vote on it and take the name. People using npm install worker would still get this package but all require('worker')s would point to the internal module.

This is much more of a courtesy notice than it is asking for permission, and it would be better, given the current situation of module names in node, for everyone, that the name worker would be used for the native worker API and not a package.

Seeing that this package has relatively few users (6 stars, ~50 downloads/mo), only strengthens that position.

In short, I gotta say I'm not overly happy with the situation, it bears a similarity to the left-pad fiasco of olde, albeit with less of a corporate tone, but I agree with Benji and Anna here.

[ghost]

I think that the choice is in his hand, since the domain name is belong to him, so even if he decide to give it or not, that's his choice.. Also, I think that Node.js Community should refactor the way they acquire npm packages from developers (Since that is not the first time!)

And the suggestion of taking the name of the package without any permission from the package owner (by votes) is really not comfort at all for the npm users (Who have improved this whole eco-system) including me. How can I be safe from any future votes that may kill my investment in my OSS project? Terrifying!

I hope the issue resolves to good choices

[benjamingr]

@Attrash-Islam

Since that is not the first time!

This is the first time Node.js has asked someone from a package name and they said "no" as far as I know. I believe this is the case because Node.js only asks for names that:

a) sound like native modules to begin with
b) don't have many popular downloads

I think in this case Node.js's mistake was not to reserve that name when we intended to use it in 2015 - 3 years before the current owner of the package has acquired it.

I do not agree that our users should be punished for the fact we did not reserve a certain package name - especially since we are not under obligation to do it to begin with.

[ghost]

@benjamingr Thanks for the clarification 👍

[vsemozhetbyt]

Strangely, for the last days downloading of https://www.npmjs.com/package/worker increases from ~50 up to ~7.000.

[MadaraUchiha]

@vsemozhetbyt It was all a conspiracy to gain more downloads all this time!

[ghost]

@MadaraUchiha Or maybe a bot 😃 Which makes more sense to prove the point that it's not only 50 downloads per month. Do you see @benjamingr ? 😂

[Linkgoron]

@MadaraUchiha
Clearly NPM just had a caching issue with the download numbers.

http://shouldiblamecaching.com/

[jskrzypek]

Actually it's probably just a bunch of people downloading the package to see what's in it / try it out. I certainly added to the the count at least once :)

[blake-regalia]

I do not agree that our users should be punished for the fact we did not reserve a certain package name - especially since we are not under obligation to do it to begin with.

The idea on display that you are somehow "punishing" users with a new module is quite inflammatory, nobody is getting hurt here. Right now its worker, next it will be http3, gpu, or whatever... if the precedent is to just take an aggressive narrative against 'those who get in my way' or even taking it by force, then you are doing something wrong -- especially considering that you are in full control of making the change to internal module scoping.

[benjamingr]

@blake-regalia

if the precedent is to just take an aggressive narrative against 'those who get in my way' or even taking it by force, then you are doing something wrong

Work with me here - let's say we make this the first module and name it @nodejs/worker or @node/worker or any of the proposed names. People are still going to try to use worker because that's what has been working for them for every core module since Node.js started.

You seem like a pretty nice person - what if at some point someone who isn't as concerned with the wellbeing of the Node.js user community shows up and that someone just exports require('@nodejs/worker) for a while - some less savvy users npm install worker --save and it works. Then, after a while longer, that someone decides to install a backdoor when the user installed worker in addition to it.

This scenario scares me, it scares me that our users will be exposed to it enough to not want to call it @nodejs/worker what should Node.js do in your opinion?

you are in full control of making the change to internal module scoping.

I think you're giving me way too much credit here. As I said before multiple times I am one person, Node is a community project and I don't call the shots. As I said before - you are welcome to participate in calling the shots if you want to.

There is no requirement for it, you could be influencing how millions of people would use the built-in node workers if you choose - that is up to you.

[xemasiv]

Come on guys since it's a powerful worker, we can use:

https://www.npmjs.com/package/superworker

It's not taken yet 😉

And months from now you and I foresee Medium articles featuring Node SuperWorkers

Sick.

Points to consider:

1. The convention of node's current require mechanism for requiring built-in and third-party modules.. trying to change it would be a head-splitting community headache. Especially for the users of previous node versions who could find it hard to adapt to new versions, and the extra confusion it will create in the documentations.
2. Using scoped names really got issues as @benjamingr said
3. npm and yarn can help by providing warnings, but their previous cli versions can't
4. npm can create an audit process for package names with node-module name conflicts but that would be a waste of time checking for malwares instead of working on our crafts
5. It's 2018 already, npm og's (like og xbox gamertags) are definitely taken already
6. Using cheesy names is fine as long as it delivers what its name should represent and it's easy to remember; plus, using them can avoid unnecessary debates and accelerate the process faster ❤️

ps: nodejs/node#20876 looks fucking sick man that's gangsta

[benjamingr]

Just throwing another idea out there and my comment from #1 (comment) more - one thing we can do is @nodejs/worker and warn when worker is required.

[refack]

Just in case it wasn't brought up earlier, the current documented consensus reached in the node core repository, is that in namespace conflicts node core should yield to the wider community's decision.

https://github.com/nodejs/node/blob/master/COLLABORATOR_GUIDE.md#introducing-new-modules

Personally I don't agree with @benjamingr opinion regarding unilateral action, but I think negotiation about the best way forward could be beneficial.

P.S. I was once the owner of the jest npm name and yielded it to FB, since it made most sense.

[benjamingr]

Personally I don't agree with @benjamingr opinion regarding unilateral action, but I think negotiation about the best way forward could be beneficial.

I think there is a good chance we won't be using worker anyway - but even if we will it won't be unilateral action but a discussion.

I'm waiting on a response for #1 (comment) at the moment.

[Scritches]

Isn't this the sort of conflict that vendor namespace prefixes are supposed to prevent?

[ShirtlessKirk]

@Scritches you'd have thought so, yes, but there's all those legacy issues already mentioned.

However, I'm with @blake-regalia here. "Asking nicely" as a "courtesy" when the possibility exists of the name just being taken anyway is nothing of the sort. That the package gets only 50 or so downloads/week or was originally from a different developer is immaterial and to use these reasons as justification for capitulation is attempting to strongarm a single developer into following groupthink.

Also, there's the implicit threat that should the name be used anyway then it breaks the standard require of this package; nice module you got there, be a real shame if anything happened to it. That's a land grab.

Then there's the throwing in of the added insults that if this doesn't happen then they aren't contributing to "the greater good" and are morally wrong in refusing. That's brigading.

It's a pity the name wasn't taken 3 years ago, but that's not @blake-regalia 's problem.

Personally, I'm surprised the dialogue is still active after the issue was deemed closed. The answer to the question was "no". Get over it and move on.

[p3x-robot]

8 stars, wow. you can create a travis daily via cron to increase your downloads, but you cannot increase your stars...
can't nodejs just override the worker name if they are not helping ?

[addaleax]

I’ve tried my best to engage in this thread in a productive manner, and I think @blake-regalia has done so as well, just from a different point of view. It’s frustrating to see the support he’s receiving to take such an (imo unjustified) accusatory tone, though.

I’m sorry that we, as the Node.js core team, seem to communicate so poorly that we are a group made out of community members, and that no single person has any say about what happens, and that no single person can alone take an action in the name of the project. @benjamingr has tried to emphasize that a couple times, and I can’t put it better than he did.

In particular, there are other Node.js TSC members that are opposed to taking a module name without the npm package owner’s consent, which is a significant hurdle to overcome if we were to go through with this.

[refack]

In particular, there are other Node.js TSC members that are opposed to taking a module name without the npm package owner’s consent, which is a significant hurdle to overcome if we were to go through with this.

I feel that statements such as this are those that are experienced as veiled threats (the if might be perceived as you reminding the reader that node-core could go the strong-arm route).
IMHO It should have been enough to state that the current consensus policy is that node-core module names should not conflict with userland module names.

[NadyaNayme]

@addaleax

It’s frustrating to see the support he’s receiving to take such an (imo unjustified) accusatory tone, though.

Or maybe certain members of the NPM team are a bit blind to their attempts at strongarming a dev into giving up the name? Maybe take a step back and do some gradeschool level introspection.

Child A: "Can I play with your toy?"

Child B: "No."

Child A: cries to Mommy "He won't let me play with his toy! Take it away from him and give it to me! I want to play with it!"

You aren't entitled to have the toy just because you want it.

Maybe try following your collaborator guide - unless you think those kinds of things shouldn't apply to you (might have something to do with a sense of entitlement).

The name of the new core module should not conflict with any existing module in the ecosystem unless a written agreement with the owner of those modules is reached to transfer ownership.

You didn't reach a written agreement. Go find a different toy.

@blake-regalia
You're doing the right thing, don't let them bully you into changing your mind.

[addaleax]

@NadyaNayme You don’t seem to be reading my replies from above here, so I won’t bother much with replying either, but I’m going to point out that Node.js and npm are different things made by different people and this has nothing to do with the npm team so far.

[p3x-robot]

@addaleax
i think you cannot take and try someone's name.
either if it is 1 or N, both are the same equality or right.
given, it is right now, is his, there is nothing so beautiful about brutal-force or new.
i give up.

[p3x-robot]

server-worker / server_worker / serverWorker / ServerWorker / server worker / Server worker etc ...