Is the npm registry restricted to JavaScript packages?

[ilg-ul]

The current Code of Conduct starts with:

npm exists to facilitate sharing code, by making it easy for JavaScript module developers to publish and distribute packages. npm is a piece of technology, but more importantly, it is a community. We believe that our mission is best served in an environment that is friendly, safe, and accepting;

I think that this is a very generous mission, especially the first part "npm exists to facilitate sharing code".

However, I wonder if this statement is true standalone, or it is linked by and AND to the next part "by making it easy for JavaScript module developers".

In other words, "npm exists to facilitate sharing code", or "npm exists to facilitate sharing JavaScript code only"?

I think that npm is indeed a great piece of technology, and the community around it provides a safe and friendly environment, but I would go one step further, and open this community to packages with other content than JavaScript modules, more specifically C/C++ libraries, which lack such a community and would greatly benefit from a packages repository.

Can someone think of this chance to widen the community, and make npm the central piece of technology for other developers too, in addition to the fortunate JavaScript ones?

[austinhuang0131]

Didn't you realize that npm stands for "Node Package Manager"? Node means node.js, so it will be javascript packages only.

[ilg-ul]

@austinhuang0131, I realised that, but I think that the potential of the npm modules repository is far greater, and it is a pity to limit it to a specific language.

what if I write (in node.js!) another tool (let's call it xpm) which provides access to the modules repository? normally the actual tool should not matter, if I respect the repository API, the server should not prevent me to connect.

[ashleygwilliams]

:wave: @ilg-ul @austinhuang0131

there are many packages in the npm registry that contain absolutely no javascript and that is both OK and encouraged!

this is an interesting request for policy change. thoughts @seldo ?

[ilg-ul]

@ashleygwilliams, thank you for your comment, I highly appreciate the open minded people behind npm.

it would be indeed a nice thing to have the policy changed to explicitly allow modules in other languages than JavaScript.

if possible Ashley, I would like you to forward this message to people in charge with making business development decision (maybe @isaacs? @seldo) since I have a proposal, to develop a set of tools to manage C/C++ modules, similarly to the way npm manages node.js modules.

I currently call this new technology XCDL/xPack, and initially I considered to store the xPacks in the ARM yotta repository, but the entire yotta design has some major drawbacks (not to mention that apparently ARM cancelled the project).

so, if Isaac, Laurie or the other gurus at npm would be kind enough to pass me their thoughts, they can contact me at ilg@livius.net, or skype: ilg-ul.

[isaacs]

@austinhuang0131 That is incorrect. npm is a package manager for all JavaScript, not only Node.

@ilg-ul To clarify what @ashleygwilliams said, npm is designed and managed to optimally serve the needs of JavaScript developers, whether they are writing code for Node.js or for web browsers or mobile phones or Electron applications or anything else.

There are several packages that are not composed of JavaScript code themselves. However, they are all oriented towards the needs of JavaScript developers. For example, many binary node modules are written in C++. Nave is written in Bash. But these examples, while not written in JavaScript, are designed to be used in concert with JavaScript development.

My concern would be that XCDL/xPack is not geared towards being a part of the JavaScript developer experience. So, this could end up in a situation where a significant amount of resources are being spent supporting a community that is (a) not part of the JavaScript community, and thus (b) outside of npm's mission to support and foster.

That being said, we've grown to a point where bandwidth and disk space are so massive, it's unlikely that your community would ever be much of an impact, next to the astronomical size of the JavaScript community. (About 5M humans using the services, at this point.) There's a good chance we simply wouldn't notice your additional load, unless it grew very large.

However, that brings up another issue. If the needs of XCDL/xPack were ever in conflict with the needs of JavaScript developers, it's likely that we'd make changes that you weren't too happy about. For example, we may change an api endpoint you're relying on, because no npm users rely on it.

While it's definitely allowed to publish non-JavaScript code to npm, npm is not in any sense a truly polyglot community. We're a JavaScript community, and we're as polyglot as JavaScript developers need to be, but no more than that.

So, if you start publishing xPacks to npm, I'm definitely not going to hunt them down and delete them. And you'll get the advantages of a worldwide CDN and much larger scale technical operations team. But you'd also be signing up for the potential for second-class treatment in the future. You could mitigate that risk by using a tool that follows the npm cli closely in how it operates, but I'm not sure how you'd go about doing that with the differences between how C++ and JavaScript operate, with respect to dependency resolution.

[isaacs]

Oh, another point, the reason that the CoC says that packages "must be npm packages" is to make it clear that we're not to be used as a general-purpose database, or a place to store your mp3 collection, or copyrighted PDF scans of textbooks. People on the internet do some weird things sometimes.

[ilg-ul]

My concern ... XCDL/xPack is not ... part of the JavaScript developer experience. ... resources are being spent supporting a community that is (a) not part of the JavaScript community, and thus (b) outside of npm's mission to support and foster.

Hi Isaac (@isaacs),

Thank you for clarifying things; I highly appreciate what you did for the JavaScript community, I acknowledge your concerns, and by all means I don't want to harm npm in any way.

if you start publishing xPacks to npm, I'm definitely not going to hunt them down and delete them

That's very kind of you, thank you for your understanding.

if you start publishing xPacks to npm ... the advantages of a worldwide CDN and much larger scale technical operations team ... it's unlikely that your community would ever be much of an impact

You are right, in the beginning probably there will be no more then some tens of packages, used occasionally by a few thousand people. Due to the specifics of C/C++ embedded development, access to the packages is needed mainly when the project is created, and is rarely needed later, since the applications are delivered in binary format.

However, even if you are not interested in C/C++ and prefer to stay fully focused on JavaScript (a position which I respect), perhaps you can remember how difficult it was in the beginning to convince people that the future is based on packages/modules, and the best way to keep track of them is via a central repository. You had a vision, and you turned it into reality, which is an extraordinary achievement.

At a smaller scale and without claiming anything close to your knowledge of the JavaScript community, I also reached the conclusion that the future of the C/C++ embedded development is based on packages, and the best way to keep track of them is in a central repository. Except the ARM yotta (now defunct, migrated to mbed CLI), all other existing C/C++ packaging solutions I know of are closed, users not being able to publish packages.

Yet, the XCDL/xPack project is more ambitious, and in the future it might grow behind the current small community of embedded developers, and be used for general purpose libraries, with the xcdl tool extended to handle more general C/C++ builds. One secret goal is to grow it to replace cmake, and be able to automate the configuration discovery by having the entire logic written in JavaScript, instead of the current cmake specific language.

So, even if now you are not interested in C/C++, please keep in mind that your experience with JavaScript might be very useful to also grow a C/C++ community (which will eventually run their builds with JavaScript tools!).

As a conclusion, if you do not have second thoughts, I'll investigate how to make xPacks a variant of npm packages, such that they can be published in the npm registry. The preliminary xcdl tool is already a npm module, and it shouldn't be difficult to use the npm-registry-client to access the registry.

As for the near future, I'm currently searching for partners and generally for any help I can get, hoping that one day my vision will also turn into reality.

So, if you decide to contribute to the design of XCDL/xPack and/or to the xcdl tool, you are more than welcome.

[hexpunk]

Didn't you realize that npm stands for "Node Package Manager"?

You sure about that? https://github.com/npm/npm-expansions/blob/master/expansions.txt