Best practices for scientific packages?

[RichardLitt]

I'm trying to figure out if there are any policies or best practices for scientific or academic projects on npmjs. I know that GitHub, for instance, now links with Orcid; Zenodo can also link directly with GitHub. Is there anything like this for npm? Are there any integrations to help citation and reference? Are there any best practice guides for new researchers looking to maximize the documentation and legs for their projects?

Thank you.

[RichardLitt]

This looks and feels like an AI answer, and it is not what I was looking for at all. I wanted to engage with someone at npm to ask if they had any best practices that they suggest.

Honestly, I can't trust your initial few sentences, having seen the rest of the post. I am disappointed.

[CopperEagle]

Hey there @RichardLitt

I would suggest you do a full standards upload to Github and use npmjs more like a mirror. Because quite frankly, the means to display relevant information is much more elaborate on Github. The emphasis on Github is development and collaboration, npmjs is more about fetching. Viewing code is in beta over at npmjs... So, publish the package on npmjs under a very similar account name, use the same README (see below) and link to the Github.

Over at Github you have two parts. One is your account. You ticked the boxes with a proper name and orcid. For the repository, orient yourself at other packages. An example here is huggingface's transformers library.

• The README should contain the bibtex citation at the end. DOI badge at the beginning of the document is also a good addition - it's immediately clear when visiting that this is not any old repository. Looks professional.
• The first few sentences of the README should directly state the paper title, author and what relation this repository has with your paper. ("This repository contains the data/code/measurements/... for ...", etc.)
• License if you publish code.

If you want to get people's expectation right, add a comment on whether you will maintain the repository. Many researchers do one publish and done. Meanwhile people go ahead and open PRs that are not reviewed.

Again, you should see Github as where people should go for viewing. So this is also the link to put in the paper. Then, if they want to install, they can do npm install rather than downloading your code from Github.

Ps. Not written by AI :)

[CopperEagle]

In any case, what are your experiences with publishing code, by the way? It's always interesting to exchange views. This topic is becomming ever more important but is rarely talked about at the institutions...

[RichardLitt]

Thank you, @CopperEagle! This is great.

GitHub does have a slightly better UX. "npmjs is more about fetching" feels accurate to me. Thank you for taking the time to cover that. I think there's a bit more to do on GitHub, but that's a bit more than I asked for, so all good.

My experience is that only large codebases that are user-facing get cited, and that no one ever cites dependencies. I'm curious about how that will play out in the long run. There are organizations - https://us-rse.org/, for instance - that are working on making research engineers more of a thing, part of which involves making software citable and recognizable as research output. https://joss.theoj.org/about is another one. But there's little for small packages, so I am trying to fill that gap and see if we can make a better workflow for scientists, especially aspirant ones, who want to make their code citable for the long run.

This doesn't even get to data or non-publishable results, of course.