There are dozens of modules available out there, many fulfilling the same task. For instance, the list of router modules alone contains 26 modules.
Given a list of modules, how can I pick the best for my needs? I am looking for one that is maintained, tested, and with some inertia, but I'm not sure how to figure out which of these modules fit that criteria.
This answer is based on a talk a few weeks ago in San Francisco by Isaac Schlueter (npm author, took over node.js responsibilities from Ryan Dahl, works at Joyent - https://twitter.com/izs )
Isaac's main project now is to improve the NPM to help people figure out the quality of packages.
Before efore the npmjs.org website gets smarter, here are factors to consider (some already listed by #3boll )
Factors
Number of downloads
How recently updated
History of updates (has it bin updated often over a long period of time)
Number of contributors
Have well-known/trusted developers and maintainers starred it? [a]
Do other important packages depend on it? [b]
Is the package well-documented and have it's own website?
Does the module have test coverage?
Github factors:
updated: As of npm 1.2.20 and forward, modules without repository fields will show a missing repository fields warning. (Nice touch to put a little pressure on people to package up their modules correctly.)
Number of forks
Number of commits
Are issues being closed on github, or have the same issues been open for a long time?
[a] example of starred
https://npmjs.org/~tjholowaychuk
[b] to quickly see from terminal:
npm view <name_of_module> dependencies
example:
npm view connect dependencies
https://npmjs.org/browse/depended
CAVEATS:
Popular doesn't mean being good. There are a lot of modules that are not popular that are really good.
Inaccurate "last updated". NPM may show a the module has been updated 2 years ago, but the github has been updated in last week. This happens if maintainer doesn't update version number as code changes on github.
This module(middleware layer for Node.js) meets your requirements:
connect — Robust high performance middleware framework
Forks about 500
+1000 commits
last update: 7 days ago.
569 npm packages depends on these module https://npmjs.org/browse/depended
p.s.
I have nothing to do with the development of the module, is just my recommendation.
Related
When bootstrapping a new Expo project with expo init ..., I see the following warning (among about a dozen others) right off the bat:
warning expo > uuid#3.4.0: Please upgrade to version 7 or higher. Older versions may use Math.random() in certain circumstances, which is known to be problematic. See https://v8.dev/blog/math-random for details.
OK, great. I understand the concern. Then, I go over here and see that, while there are some possible breakages, I went through and verified that none of the calling code seems to run afoul of them. Then, using Yarn resolutions, I add this to my package.json:
"resolutions": {
"uuid": "7.0.3",
...
}
Next, I delete node_modules and yarn.lock, and yarn install again, and now I get this warning:
warning Resolution field "uuid#7.0.3" is incompatible with requested version "uuid#^3.4.0"
So, essentially, I've traded one warning for another. What I really want here is an error and warning free build. I'm willing to accept responsibility for the breakage I might cause by pinning "incompatible" versions. Or if I could turn these warnings on/off (one by one) somehow, it'd be suboptimal, but I'd probably be fine with that.
I come from a previous life of developing safety-critical systems in C & C++, where we operated under a doctrine of 'warnings are errors waiting to happen; no warnings allowed ever.' I've noticed from looking at many other Node.js projects that many folks working in this ecosystem seem to just say, "Warnings? YOLO!", and I can see why, TBH. When the problematic dependency is a 7 layer deep, transitive dependency (all 7 of which you didn't write, don't "own", and are unlikely to be able to edit/fix, and 6 of which you didn't even explicitly ask for) I can see how it might be easy to say, "Not my problem!" and push onward.
But is it really the case that there's just no hope for a warning free build? I thought resolutions would be the solution to this, and it was helpful for one dependency that was a "compatible" version, but I'm driving myself nuts trying to figure out how to simply get a clean build on an effectively empty (i.e. no code of my own) project. There have to be companies/teams out there with similar desires, so I'm assuming there's some solution I'm not aware of. Does anyone have any hot tips?
I've tried:
yarn resolutions (as described)
npm-force-resolutions (seems like an abomination -- it edits your packages-lock.json, requires 'double installing')
force-resolutions (which looks like just a newer fork of npm-force-resolutions, and has the same issues).
I've read about NPM v8.3's overrides (and it looks promising, TBH), but Expo's cloud building service uses NPM v8.1, so that's off the table until some nebulous moment in the future.
I just can't believe this an unsolvable problem, or that I'm somehow the first person to try to solve it. Thanks!
I am trying to create a project structure to my team like how it implemented by open-wc or create-react-app
just say npm init #open-wc and it asks couple of questions and creates the folder with specified configurations.
I didn't find good articles on google except exploring the github projects.
Maintainer of open-wc here :)
So to get an npm init script all you need to do is define a bin in your package.json.
This is what we use for npm init #open-wc:
"name": "#open-wc/create",
"bin": {
"create-open-wc": "./dist/create.js"
},
So then for the name you have 2 choices:
create-foo will be available via npm init foo
#foo/create will be available via npm init #foo
The generators itself
That's a rather sad story... we looked around but we didn't find anything that really fit our use case well. There is http://yeoman.io/ which we used initially but it's huge and it meant we had a bootup time of ~30-40 seconds before the menu appeared. We felt we needed to do something so now we roll our own solution.
It covers what we need now with a fraction of the size (especially by being very careful with dependencies) which reduced our bootup time to about ~5-10 seconds.
We thought about promoting it as a separate standalone project but truth be told we don't have the manpower for it. It's just 4 files you can find here https://github.com/open-wc/open-wc/tree/master/packages/create/src - beware as there is no docu and quite some rough edges.
Still, if you don't find a better solution feel free to join us and with some help, we could make it a separate product.
I downloaded NodeJS and installed it on windows 10.
I updated npm using the npm install npm#latest -g command line
I neither used github nor anything else
I get the message "created a lockfile as package-lock.json. You should commit this file".
What should I do to commit the file?
what happens when I commit it?
what happens if I don't commit it?
Please do not quote the npm documentation, as I read it serveral times and did not undestand it.
Thanks
Thank you – jdubjdub & – SilverWolf - Reinstate Monica for your cogent remarks. Yours were the comments that led to my eventual comprehension; years after the fact for you, hours after the fact for me.
I know this is an old post and the OP and OC's are likely to never see this answer; I am dealing with this problem for the first time and have typed into the browser a reformulation of this very question many times today. I was near to trying the patience of some of the genuinely gifted people on Stack Overflow, attempting clarification for my own elementary version of the question.
I have finally come to recognise the term "commit" is not as alien as we thought. It is what we thought it might have been. It's the same as on github as when we commit anything that we have changed and want other contributors (or authors) to see.
I have a github account and git installed on my computer. After about an hour of docs and man pages I did not put all the dots together until I read the comments on this page and then it all finally just became so perfectly clear. Commit is the same concept on github as is being referenced in my terminal: npm notice created a lockfile as package-lock.json. You should commit this file. And since I am not actively working on a project I can disregard the warning. Also, some argue the merit of ignoring it even if I were on production. But that's beyond the scope of this post.
Those whom only rarely use git or gitHub, have only the vaguest grasp on how one performs version control. The term "commit", even when mentioned frequently in answer, does not necessarily obviate all but the one meaning or action.
Our friends may not fully appreciate our incomprehension of the term "commit" in this context. We were thinking (in my naivete, at least I was) that there may be more than the one meaning to "commit" we are familiar with i.e. from github.
I guess these are just such a common abstract for anyone doing version control they assume since we've gotten this far we must grasp the nomenclature and are really puzzled by the deeper fundamental aspects of the underlying processes and procedures.
If you would like a more robust definition on exactly how (and why) to commit check this out: github:https://help.github.com/en/desktop/contributing-to-projects/committing-and-reviewing-changes-to-your-project.
I should note there are many free and paid version control tools available. Here is not an exhaustive list containing 15: https://www.softwaretestinghelp.com/version-control-software/.
And here the github desktop app:
https://desktop.github.com/.
I'd like to snapshot the global Hackage database into a frozen, smaller one for my company's deploys. How can one most easily copy out some segment of Hackage onto a private server?
Here's one script that does it in just about the simplest way possible: https://github.com/jamwt/mirror-hackage
You can also use the MirrorClient directly from the hackage2 repo: http://code.haskell.org/hackage-server/
This is not an answer two the question in the title but an answer to my interpretation of what the OP wish to achieve.
Depending of what you want for level of stability in your production circle you can approach the problem in several ways.
I have split the dependencies in two parts, things that I can use that are in the haskell platform (keep every platform used in production) and then only use a small number of packages outside that and don't let anyone (including yourself) add more packages into your dependency tree just because of laziness (as developer). These extra packages you use some kind of script for and collect from hackage (lock to version) by using cabal fetch. Keep them safe. Create a install script that uses your safe packages and if a new machine (developer) are added to your team, use that script.
yackage is great but it all comes down to how you ship your product. If you have older versions in production you need to have a yackage setup for every version and that could be quiet annoying after a couple of years.
You can download Hackage with Voker57's hackage-mirror.sh. You'll need 'curl' for it to run. If you're using a Debian based Linux distribution, you can install curl by typing apt-get install curl.
Though it's not a segment of Hackage, I've written a bash script, that downloads the whole Hackage, what can be further easily set up as a mirror using an HTTP server. Also, it downloads all required stuff like GHC compilers ready to be used with Stack.
Currently, a complete Hackage mirror occupies ~10GiB (~100000 packages of all versions) and Stack related stuff like GHC compilers ~21GiB (~200 files). Consequent runs of the script skip already downloaded stuff, so it downloads only new one. So it's a pretty convenient way to "live offline" and sync up to date when online.
I have a package on Hackage which depends on third-party package, which doesn't build on newer versions of GHC (>= 7.2). The problem with the other package can be solved with just a one-line patch (a LANGUAGE pragma). I sent the patch to the upstream twice, but didn't receive any feedback. The problem is that my package is not installable neither until the dependency is fixed.
I could have uploaded the fixed version of depenency package (with a minor version bump), but I'd like to hear what is the attitude of the community about such non-maintainer uploads. Again, I don't want to change the library interface, I only add a new compilation flag to make it buildable again.
Are non-maintainer uploads to Hackage allowed and tolerated?
When a fork of the package on Hackage is a better approach?
Package uploads by non-maintainers are allowed (there may be license issues, but most packages if not all on hackage have licenses permitting this), but of course they are not usually done. They are tolerated if done in good faith and with reasonable procedure. If you contact the maintainer and don't get any response within n weeks (where I'm not sure what the appropriate value of n is, not less than 3, I'd say), uploading a new version yourself becomes an option, discussing that on the mailing lists seems however more prudent. If the package looks like it is abandoned, even taking over maintainership - of course after again contacting the maintainer, giving her/him time to respond - may be the appropriate action, but that should definitely be discussed with the community (haskell-cafe or mailing list, for example). Whether to prefer a non-maintainer upload or a fork must be left to your judgment, personally I tend to believe forks step on fewer people's toes.
But a better founded reply would be possible if we knew which package is concerned and could look at the concrete situation.
A forking is intrusive for a package that you suspect is still maintained but the author is temporarily missing. By intrusive, I mean that other programmers might pick up your fork then not go back to the mainline once the original author has resumed work on the mainline.
For packages where the original author has left the Haskell community, my personal opinion is that its better to fork the package if you are going to develop it further. Forking prevents succession problems, such as those that happened with Parsec where many developers didn't want to update because the successor was slower and less well documented than the original for some time.
In all cases asking on the Cafe is best, regardless of whether people have chosen not to follow it, it is still the center of the Haskell community.
For the particular case in the question, while it is nice if things on Hackage compile, there is no rule that says they have to. A package that depends on a broken package could simply put change instructions for the broken dependency on its front page, i.e. "This package depends on LambdaThing-0.2.0 which is broken, to fix LambdaThing add ... to the file Lambda.hs"
I would say, it's a very good idea to consult the mailing lists regarding the specific package and the specific person who is missing. I took control of the haskell-src-meta package from its original owner, but only after consulting with the lists and IRC, who assured me that Matt Morrow had been missing for months and no-one knew why.
In my opinion, package ownership should probably only be changed where there is a consensus to do so, or at the very least there should be efforts made to find one. In the development version of the Hackage software, it's my understanding there are access controls so that only administrators can make this kind of intervention.