Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some more possible destinations #174

Open
mrienstra opened this issue Sep 29, 2022 · 9 comments
Open

Some more possible destinations #174

mrienstra opened this issue Sep 29, 2022 · 9 comments

Comments

@mrienstra
Copy link

Neat tool! I can see how it will save time if I remember to use it!

Some of these are kinda random, some of these I actually use, but thought I'd just go for it, in case any of them strike a chord.

https://npmtrends.com/njt

npm-audit: https://www.gyanblog.com/tutorials/how-node-npm-audit-rest-api-vulnerability/

https://npmgraph.js.org/?q=njt

https://snyk.io/advisor/npm-package/njt

https://socket.dev/npm/package/njt

https://techgaun.github.io/active-forks/index.html#https://github.com/kachkaev/njt

@kachkaev
Copy link
Owner

kachkaev commented Oct 3, 2022

Thanks for sharing these links @mrienstra – some of them are new to me!

I'd be interested in adding more tools, but I’m not quite sure how to elegantly go beyond one-character keywords. I’m afraid that if we introduce too many shortcuts, people may start jumping to wrong URLs, which will bring more harm than benefit.

I wonder if there’s room for something like d for dashboard, which would open njt.vercel.app/-/packge-name. That new page can contain links to all tools including those without direct shortcuts 🤔 WDYT?

@mrienstra
Copy link
Author

mrienstra commented Oct 3, 2022

That's a cool idea! Although I think I'd prefer keeping that second step in the CLI, something like this:

  1. User enters njt <package> without a destination (current behavior would be to default to n)
  2. Show a list of destinations sorted by keyword, something like this:

image

  1. ... with a prompt as well of course. Accepting input as soon as it matches a keyword (and if you introduce two-character keywords, if there isn't a longer keyword that start with the same character) without needing to hit enter would help keep the number of keystrokes low.
  2. A nice touch would be to delete most of those lines from the CLI after a choice was made, leaving only a summary of the flow.

Here's how that might look with 2-character keywords:
image
(added pp from #172)

Personally, I don't think two-character keywords would be all that terrible, but I definitely think most users will only be a actively using a few.

I've been pondering the addition of a config, so users can change the default keywords as desired, maybe disable destinations they don't plan to use, or otherwise tweak the behavior.

Edit: screenshots above cobbled together with this code.

Edit 2: with aliases:
image

Edit 3: The above is CLI-centric, but something similar could be done on the website (keyboard shortcuts, minimal keystrokes, option to keep hands on keyboard).

@mrienstra
Copy link
Author

If you decide to go this route, check out prompts. I ran across it recently while contributing to astro, which uses prompts for two CLI tools.

@mrienstra
Copy link
Author

Down to work on this if you'd like.

Also, small detail, but the prompt could show a default entry of n for npmjs.com, so immediately pressing enter (without other entry) would take you to npmjs.com.

@kachkaev
Copy link
Owner

👋 @mrienstra! njt CLI is just one of several user interfaces (entry points) for njt. If we add more keywords and figure out UX for cli, other environments like browsers, Alfred, etc. may degrade UX-wise. More keywords means more cognitive load on a human and therefore higher chances of landing on the wrong page.

Before we add more keywords, what we probably need is a universal way of providing search prompts for the query (like Google does when we type text in the browser’s address bar). Maybe we should explore this direction first, find a universal solution and then port it to all interfaces we have (which will include CLI). WDYT?

@iamandrewluca
Copy link
Contributor

iamandrewluca commented Nov 22, 2022

Some of my insights.

I'm using this package extensively, daily.

My most used shortcuts are s n b u c d

I'm using this package because it increases speed drastically.
I even had an attempt to add a cache layer for njt results to increase the speed even more.

Personally, I wouldn't mind having shortcuts that will use 2 letters. After you learn them it is very easy to move around.

Having a way to set your own, or disable some shortcuts could also be a nice solution.

Do we have any analytics on what are the most used shortcuts, or how many users use njt?

Having services with the name of 2 words we can use their initials:

  • bundlephobia ➡️ bp
  • packagephobia ➡️ pp
  • npmtrends ➡️ nt
  • npmgraph ➡️ ng
  • ...

@kachkaev
Copy link
Owner

kachkaev commented Nov 23, 2022

I suggest that we figure out search autocompletion first as it will help with navigating between more destinations. We can frame the feature like this:

As a user, I should be able to type njt[space]prettier[space] and see a list of destinations.

I don't have any experience with this kind of stuff bu I believe that we need a new API endpoint which can be auto-discovered by Chrome, FF, Alfred etc. When this is sorted, we can add autocompletion support to njt.vercel.app and CLI. This will unblock pretty much any number of destinations we want. Adding two-letter destinations now will make the tool harder to use because it's difficult to remember a lot of abbreviations.

@iamandrewluca
Copy link
Contributor

One more possible destination

Find the true size of an npm package.
https://pkg-size.dev

@iamandrewluca
Copy link
Contributor

One more possible destination

browse type documentation for npm packages
https://tsdocs.dev

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants