privatenumber / pkg-size.dev

📦🔍 Find the true size of an npm package
https://pkg-size.dev
688 stars 6 forks source link

Suggestion: Unify command input / NPM search #1

Open barelyhuman opened 1 year ago

barelyhuman commented 1 year ago

Instead of having the refresh/reset button uptop, it'd be easier to keep the command input active and unify the webcontainers output in a sub terminal, making it easier to change what was installed.

barelyhuman commented 1 year ago

Adding an NPM search would help by avoiding requesting for non-existed packages, This might be out of scope so can be avoided

privatenumber commented 1 year ago

Could you please clarify what you mean by "sub terminal"?

I decided not to keep the terminal active for the following reasons:

  1. The more I rely on the terminal as a user interface, the more functionality I would have to add to make it a fully functional terminal. However, this would require a significant amount of work, which may not be justifiable.

  2. There was a sense of irony in having users interact with a website through a narrower and more basic user interface, such as the terminal, when websites have the potential to provide a richer and more immersive experience.

  3. I couldn't find a suitable way to integrate the terminal into the user experience flow of moving from Terminal -> Install Size -> Build Size. Specifically, it was confusing to have install size results while still interacting with the terminal in the previous step.

Could you provide a design or illustration to better visualize your concept?


Regarding the second part:

Adding an NPM search would help by avoiding requesting for non-existed packages, This might be out of scope so can be avoided

I'm not entirely sure what problem you're trying to address with this suggestion. Could you provide more context or explain the specific issue you are referring to?

barelyhuman commented 1 year ago

I decided not to keep the terminal active for the following reasons

Make sense, though I think that if it's being shown for both execution the people would try to interact with it, I'll try to design something

I'm not entirely sure what problem you're trying to address with this suggestion. Could you provide more context or explain the specific issue you are referring to?

I thought you spun up a web container for each install, so if I was accidentally typing a wrong name and pressing enter, it'd cost the page resources. I want to confirm if the container is only initialised once then the request can be ignored altogether

privatenumber commented 1 year ago

The WebContainer is only instantiated once per page-load. Each npm install spawns a process in the same WebContainer but in a different directory.

privatenumber commented 1 year ago

(Accidentally closed)

barelyhuman commented 1 year ago

Based on the new knowledge of the working and flow, here's the thoughts and a rough sketch.

New Drawing

  1. A big card in the center of the screen (very similar to bundlephobia) but instead would still have the npm install and the blinking cursor you have. We move the "starting..." message down to a tiny badge styled alert after it. I'll get to why in a bit.
  2. We avoid the terminal view of installation since while the webcontainer is exciting, there's now 2 loading bars on the screen , one from the container when npm is installing and one on top of the terminal window. One of them can be hidden and just an opinion but I think hiding that would make it a little more aesthetic
  3. This is just minor layout based mods that you can ignore but the pkg dev logo grabs more attention than the terminal and the title of the terminal window. This isn't an issue but there's a tiny lag when you start typing before the container has started and so it'll help making it easier to focus on the point of action if the logo was smaller and up top

This is while keeping the current look of the entire app. If you don't mind changing the overall look then I'd implement something like tasuku's list execution UI with the terminal instead.