discussions
enquirer
discussions | enquirer | |
---|---|---|
1 | 19 | |
149 | 7,504 | |
0.0% | 0.5% | |
10.0 | 4.9 | |
over 9 years ago | about 1 month ago | |
JavaScript | ||
- | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
discussions
-
NPM Vulnerability Discussion on Twitter
The question in that thread, and this later thread,[1] is how to know which keys are valid to sign a package.
For example: I go to release a new version and I've lost my private key, so I roll a new one -- this will happen often across npm's 1.3 million packages. Do I then ... log in with my email and update the private key on my account and go about my business? What process does npm use to make sure my new key is valid? Can a person with control over my email address fake that process? How are key rotations communicated to people updating packages -- as an almost-always-false-positive red flag, or not at all, or some useful amount in between? If you don't get this part of the design right -- and no one suggests how to in those threads -- then you're just doing hashes with worse UX. And the more you look at it, the more you might start to think (as the npm devs seem to) that npm account security is the linchpin of the whole thing rather than signing.
It's not just npm; that thread includes a PyPI core dev chipping in with the same view: "Lots of language repositories have implemented (a) [signing] and punted on (b) and (c) [some way to know which keys to trust] and essentially gained nothing. It's my belief that if npm does (a) without a solution for (b) and (c) they'll have gained nothing as well." It also has a link from a Homebrew issue thread deciding not to do signatures for the same reason -- they'd convey a false expectation without a solution for key verification.[2]
[1] https://github.com/node-forward/discussions/issues/29
enquirer
-
GitHub Sponsors: Jon Schlinkert JavaScript developer
jonschlinkert (Jon Schlinkert) · GitHub
-
For achieving the widest adoption among Windows users, which commonly used scripting language would be best suited for a CLI program?%
Although I'm happy there is a way to bundle Node.js apps with support for pnpm, and for a modern-ish version of Node.js, it's somewhat slow in my experience to build locally. Interactivity doesn't have the greatest ecosystem there, especially with TypeScript. Best library I've found is Enquirer.
-
💡 Generate package.json From GitHub
{ "name": "@jonschlinkert/omit-deep", "description": "Recursively omit specified keys from an object", "tags": ["object", "deep", "remove", "omit"], "version": "0.3.0", "author": "Jon Schlinkert (https://github.com/jonschlinkert)", "repository": "jonschlinkert/omit-deep", "bugs": "https://github.com/jonschlinkert/omit-deep/issues", "license": "MIT" }
-
Using generators to improve developer productivity
In case you need to ask for user input, optionally you can use a prompt file. This is very useful to customize the output of the generator. Prompts are defined using a library named Enquirer.
-
NPM Vulnerability Discussion on Twitter
> I don't fully understand why packages like this are so popular.
It actually works like this: Author X develops `iseven`, `isodd`, etc. No one really downloads such packages. Author X then develops `importantPackage` which does do something useful developers out here download. Now `iseven`, `isodd` are downloaded alongside `importantPackage`.
My point is, we should recognize certain NPM authors as toxic, but I guess "freedom of speech/code" stops us from doing so. Example of such an author: https://github.com/jonschlinkert/
-
Call for Deno module ideas
something like enquirer
-
I will pay you cash to delete your npm module
You're thinking of Jon Schlinkert, publisher of 1435 packages on npm.
-
NPM – is-even, 160k weekly downloads
It's insanely funny to me that these packages exist while one of his bigger projects (https://github.com/enquirer/enquirer) lists the following reason under "why use it":
> Lightweight - Only one dependency, the excellent ansi-colors by Brian Woodward.
-
BREAKING!! NPM package ‘ua-parser-js’ with more than 7M weekly download is compromised
It's written by this guy, who shits out micro libraries by the hundreds. He moved the project to another user under the pretense that he was learning to program back then, but a lot of his stuff is similarly inconsequential micro libraries.
- NPM Audit: Broken by Design
What are some alternatives?
rfcs - RubyGems + Bundler RFCs
prompts - ❯ Lightweight, beautiful and user-friendly interactive prompts
oclif - CLI for generating, building, and releasing oclif CLIs. Built by Salesforce.
deno - A modern runtime for JavaScript and TypeScript.
deno-puppeteer - A port of puppeteer running on Deno
ua-parser-js - UAParser.js - Free & open-source JavaScript library to detect user's Browser, Engine, OS, CPU, and Device type/model. Runs either in browser (client-side) or node.js (server-side).
terminalizer - 🦄 Record your terminal and generate animated gif images or share a web player
cli - the package manager for JavaScript
npm-force-resolutions - Force npm to install a specific transitive dependency version
audit-ci - Audit NPM, Yarn, and PNPM dependencies in continuous integration environments, preventing integration if vulnerabilities are found at or above a configurable threshold while ignoring allowlisted advisories
remarkable - Markdown parser, done right. Commonmark support, extensions, syntax plugins, high speed - all in one. Gulp and metalsmith plugins available. Used by Facebook, Docusaurus and many others! Use https://github.com/breakdance/breakdance for HTML-to-markdown conversion. Use https://github.com/jonschlinkert/markdown-toc to generate a table of contents.
MediatR - Simple, unambitious mediator implementation in .NET