The npm community forum has been discontinued.
To discuss usage of npm, visit the GitHub Support Community.
tink: New search UI
that’s a pretty new bug… @bcoe???
No need to configure Babel! tink already supports jsx out of the box:
Though if that doesn’t work (it should), I’d rather just write out the entire thing using raw
h() calls and we can revisit this later when I can fix jsx support (or if you want to fix it, go for it). I don’t expect that to be any more painful than plain jsx.
Ink 2 is out, let’s migrate to Ink 2!
If you’re familiar with React, this is a fantastic contribution to make!
I’m making this thread separately from tink: Implement ancillary subcommands because it’s more involved and I want more back-and-forth about the implementation.
I’d like a shiny new search command that allows interactive search + installation of packages from those results. The command should display things significantly better than the current CLI search and act as a damn good alternative to searching on the website. Additionally, it should use the new search endpoint off the configured registry instead of a third-party one.
tl;dr I’d like something like
emma cooked directly into
tink, but using tink for installations, and npm’s new search endpoint instead of Algolia. This command, depending on how it works out, is very likely to get slurped into the npm CLI proper eventually. Also, although
npm-suggestions is really cool, please don’t use that endpoint – it’s going to fall over as soon as npm’s userbase starts hitting it, and npm, Inc will need to build (and scale) its own version of this before we can do it.
My sketch for the UI is something like this:
$ tink search (no arguments = interactive mode. arguments = api mode) Find a package: foo Results: > foo @zkat p 95 q 41 m 69 bar @iarna p 100 q 84 m 35 baz @isaacs p 80 q 80 m 80 ... ...(53 more) Full Description: Does a foo thing and also this is a very long description, with the text wrapping on the bottom like this.
OK, PR is open!
I’ll continue code discussion over there…
and to answer your question: The “Right Way” to do it is to pass the entire
opts object over to
libnpm.search. Because of
figgy-pudding, this is the way we handle the large number of npm-related options that are otherwise impractical to pass through layer by layer.
I have already submitted a PR for migrate ink-table to v2.
This all sounds great!
So—caveat—I haven’t contributed a whole lot to open source, so I will probably ask lots of dumb questions.
If I have any questions for you, I assume this is the place to do it? Do you have a timeline you’re aiming for for a PR?
Thanks, excited to dig in!
It is really rad, and kind of blowing my mind…
Why don’t you grab the view one, and you two can work together to integrate them? My evil plan was to make it so the “Full description” desction is actually replaced by a
<PackageView /> once this was done, so you basically get to see all the general info about a package right in the search screen.
Totally missed the
.jsx extension! I changed it but still no dice, and I think I see why…
I registered my command in
bin/tink.js similarly to the others, by adding this to it:
So because the
require is happening there and the JSX overrides aren’t
runCommandWithYargs is run, the commands are showing up too early to catch the JSX boat.
I tried switching those
CMDS to strings and requiring them in the for loop in
runCommandWithYargs and hit another error:
Class constructor Color cannot be invoked without 'new'. Apparently it’s something to do with ES6 class transpilation (or lack of…? I found an issue about it here).
Anyway, I wanted to capture all of that for reference, but I’ll just stick with
h() for now . Seems like you’re still sizing up
ink, so it’s probably not worth sinking too much effort into tooling for it just yet.
go ahead and open a PR!
that is so exciting. I never thought I’d be so thrilled at having JSX available somewhere other than web code lol
A note about this: Please just put a placeholder that says “Adding packages…” and finishes on a ~1s timeout. I’ll have an API for you eventually to call but I’m working on rewriting the installer and resolver right now so you won’t be able to test any of this until that’s done.
This sounds incredibly fun, and the
tink view one too! I assume some communication would need to be done with people working on that if those components are going to be used here? Perhaps some components like
<Field path="dist.tarball" /> or
<View style="oneline" />. If this one’s claimed already, I’m happy to work on
tink view too.
Alright so I’ve got a WIP branch (
feature/search-command) up here if you wanna check out my progress so far:
To use it:
./bin/tink.js search or
./bin/tink.js search "some term". I set it up so that if you don’t enter a term at command execution, it’s interactive, and if you do, it’s still interactive, it just fills your term in the input and auto-executes a search for you.
The main thing I’m still working out is input focus. It’s kind of weird in context of a CLI, but I installed
ink-text-input to handle the search terms input, and
ink-select-input to handle results listing/selecting and there’s a sense of “focus” I need to nail down. Currently if you search, then select a package (hitting Enter on a highlighted package), it will select the package and submit the search again. Shouldn’t be too tough to iron out.
And I didn’t address CLI arguments really, aside from the one optional positional argument for search terms. I included the options in
lib/common-opts.js, but maybe those are mostly irrelevant here?
json jump out, but I’m guessing there’s no standardized registry search API, and for
json we could just dump JSON of the matches if that’s desirable. Now that I’m thinking about it, it probably makes more sense to just expose arguments that get passed in for
libnpm.search. Would be pretty sweet in particular to be able to sort results by popularity, quality, maintenance, etc.
The flow so far is pretty rough, but working. It’ll be nice to polish it up, show a nicer “Installed” message, handle errors nicely, etc. It’ll definitely be good to look into accessibility too. I assume since this is an all-text interface it’s probably mostly good but I wonder, for example, if the little arrow selector for package matches is accessible…
I assume it might be good to get either this or @larsgw’s work over here merged, and then integrate the
PackageView here. I assume the intended functionality is: as you are perusing up and down through search results, as you highlight one you see a
<PackageView /> with a bunch of details below the search results list, is that accurate?
Let me know if I should open a WIP PR to the
tink repo—would probably be easier to talk about the code and exchange feedback there.
Can you try rebasing onto the latest tink? I’ve been thrashing around the past few days. I think a recent patch will probably fix that for you. Beware this may involve changes to how your command is set up.
You can discuss it in this thread (it’s what #development is for!), or if you don’t want it to be so public, you’re totally fine DMing me (assuming you can do that by now?).
FYI: tink: Implement tink view was merged!
Tink is using
ink-table, let me migrate
ink-table to Ink 2 first!
Oh nice! I get an
Unexpected token < error when I try to use JSX-ish stuff. I’m testing this way:
./bin/tink.js search "florp"—I’m wondering if I might need to use it some other way to pick up that JSX snazziness…? I see some magic happening in
Hey there, just wanted to check in! I’m still getting my mind around
ink (seems pretty rad, and so weird using React for a CLI…), borrowing heavily from the
emma CLI, and I’m hoping to have something rough to share in the next couple days.
I was going to ask if I should configure Babel so we can use JSX (it looks pretty simple), but I know that would involve a
dist/ directory of some sort and pointing the
bin/ stuff at
dist/ (and probably other things I’m not aware of…). I caught up over here and you had mentioned not using JSX for the
view. Would you like to avoid JSX altogether? Or should I get it configured for search view?
Hi there, I would love to help with this! I’ve been doing lots of React and searchy things (Elasticsearch) lately and I’ve been particularly interested in working more with developer-facing interfaces/DX and would be stoked to learn from and collaborate with you on this.
Looks good! I’ll finish the updated
As for feedback, one quick point: aliases seem to be handled at two levels, causing duplication in the
tink help view. However, this is a problem for @zkat’s commands too.
Commands: tink completion generate bash completion script tink shell Launch a tink shell or execute a script [aliases: sh] tink shell Launch a tink shell or execute a script [aliases: sh] tink search Search the NPM registry [aliases: s, se, find] tink search Search the NPM registry [aliases: s, se, find] tink search Search the NPM registry [aliases: s, se, find] tink search Search the NPM registry [aliases: s, se, find] tink prepare pre-fetch all dependencies [aliases: prep] tink prepare pre-fetch all dependencies [aliases: prep] tink ping ping registry [aliases: prep]
Good to know.
yes, this is accurate
Pretty sure it’s fully fixed now. Can you rebase one more time onto
latest and try again? If this one doesn’t work, we can definitely go ahead and fall back to h()
Yay it works! Thank you so much!
Oh and of course, remember your command has have a . jsx extension
Yeah, a bit too hesitant in the end . Didn’t want to hog such cool projects…
All yours, then! Let me know if you have any other questions.
Thought I see @larsgw is typing…