joshwcomeau / guppy Goto Github PK
View Code? Open in Web Editor NEW🐠A friendly application manager and task runner for React.js
License: ISC License
🐠A friendly application manager and task runner for React.js
License: ISC License
As discussed in #130, we want to use React Storybook to host a catalog of reusable components. The infrastructure work is complete, and now we need to write stories for existing components.
This issue tracks the progress we've made against our existing components.
Note that not every component will need a story; we should only create stories for components we anticipate being reused.
The goal for creating stories should be to show off how the component can be used; it's a tool for discoverability. This means that each component should have at least 1 story that mimics its in-app usage. We also want to create a variety of stories for each component to show off how its props can be used.
This is clearly too much work for a single person to take on, but I figure we can tick items in as they come in; just add a comment linking to a PR, and mention the component(s) it covers, and I'll add info to the list and tick the box.
Some components will have special requirements. I've given them different annotations. See the details below the list.
react-icons-kit
, but we should still create a story to show how we use it!)¹ This component uses Electron methods, so it may be more trouble than it's worth to get it working in the browser.
² This component needs to have some state managed for it for the story to be useful. We'll need to build a little state-manager component for it, within the story. TODO: Add a link to an example.
³ This component is a screen-size helper. The story should make clear that the user has to resize their window to see its effect.
As a desktop application, guppy should support an application menu. A minimal version of this is needed to support "Select All", "Copy", "Paste" ... in text fields. It's also needed for adding keyboard shortcuts (and letting (macOS) users customize them via System Preferences for free). Let's collect the things that the menu should contain / do in this issue before we implement it.
Minimum
Additional Possibilities
While menus like Tasks, Dependencies, or Recent Projects in File, that actually list the items, are in line with desktop app conventions, managing dynamic menus is a bit of a pain with electron so I think it's a fairly low priority for now. The Tasks menu would be the most valuable, since it would allow adding keyboard shortcuts to tasks. Creating a static menu, since tasks can't be added and removed either for now, would be an option.
Currently, there's no way to "edit" a project. A few common tasks will be needed:
This can either be another module at the bottom of the project page... or maybe it should be a modal, accessible by clicking a "gear" icon? TBD.
Also, deleting the project should be in the application menu
Currently, Guppy only works on MacOS. We should aim to build it for Linux as well!
Windows support is tracked in #27.
This ticket is sorta blocked by #26 - if we're gonna switch to electron-builder, we should do that before spending time/energy on a Linux installer solution. Although I'm also cool if someone doesn't wanna wait for that to submit a PR that adds Linux support.
To reproduce, go to any project, click “Add New Dependency” and search for “prettier-stylelint.”
Some observations:
@goodforonefare/prettier-stylelint-formatter
, wraps and causes the button text to wrap, too. Perhaps the button should be set not to wrap?_highlightResult
key’s properties where possible to highlight the matched text.While using Guppy on a side-project, I realized that it gets kinda slow/sluggish after a while.
I believe this is because the Development Server outputs all text, forever. The longer it stays open, the more DOM is added, and it gets to be a lot.
One easy solution could be to clear the terminal whenever it rebuilds. Another slightly trickier solution could be to virtualize the offscreen content (tricky since each log entry is of unknown height).
We should also see if it's sufficient to just not put it in the DOM, or if we should also delete it from Redux. If we keep it in Redux, we'd be able to show history on demand.
Right now, only a single test file exists, for the Tasks reducer.
This project is still very early, and I expect the UI to change dramatically, and so I'm not so concerned with UI tests, but our core business logic should really have more tests.
Some files I think are top-priority for testing:
If anyone wants to tackle some of these files, please let me know (we can create new issues to track just the file(s) you want to test). The current tests in task.reducer.test.js
should serve as a rough guideline for creating new tests.
It would be great to get the application bundled in CI, to test that everything works properly. This will also be helpful once we have more tests!
While installing dependencies, both during step 4 of project creation as well as when adding them manually to an existing project, the UI simply displays an indeterminate spinner until the dependency is installed. To new users, this may be concerning, especially if they are running on older hardware (redux took well over two minutes on my 2011 MBP). NPM's CLI displays a progress bar at the left of its output, so it should be trivial to hook into this and use it to display a more visually appealing distinct progress bar in the UI so users will confidently know that a long-running process is in fact still running and not stalled indefinitely.
I'll work on the logic, but I'm nowhere near @joshwcomeau when it comes to design so any help with styling would be much appreciated.
What's the point to install the application?
I like the way you go, but it's weird to install application on your pc. It's cool to contribute to this project, and I would want too but would be better to point at something important.
Modern applications tend to use in the browser, not install on your pc and all this stuff.
Besides this arise some problems with the community. You have no ability to share your application, or even see other ones. Either if you do this ability, you should copy your link and share but when you visit this link you have to install application :( .
When you create a new project in Guppy, it asks you to select an icon.
Once the project is created, though, there is no way to update that icon.
For imported projects, it's even worse; you just get a random color and the first letter of the project name.
Ideally you should be able to change icons whenever, as well as upload your own, or choose to automatically use the favicon for the project (especially for imported ones).
This issue should be done, ideally, after #28, so that the new icon functionality can be used in both places.
This issue encloses several tasks:
.guppy
directory in the project (I think it has to live in the same directory as the project..?)have a nicer handoff from the installation to starting development by having a button that opens straight to IDE. you can use launchEditor from react-dev-utils, it should jsut be a few lines. the harder part is where to put this in the UI
The link takes you to https://github.com/%5Bobject%20Object%5D
instead of the actual page of the dependency.
I'm running the latest release version.
Right now, the Guppy logo is the Apple "tropical fish" emoji (assuming you're on a mac, 🐠)
This is likely a copyrighted thing, though, so we should really get a custom one.
I've purchased no fewer than 3 logos on Fiverr, and I've since learned that there's a reason everything is so cheap on Fiverr. I haven't been super happy with any of the results.
If any graphic designers are reading this, help! Ideally the Guppy logo should be similar in tone/feel to the Apple tropical fish emoji; a round fish with some interesting gradients/patterns. Ideally it'd look more serene, maybe with a subtle smile?
A big part of Guppy is the ability to run tasks (AKA NPM scripts).
For most tasks, this is fine; a command is sent, and then output is logged to the screen.
The CRA "eject" script, however, has a warning prompt that requires the user to enter "yes" or "no". In our case this prompt is unnecessary (since the UI has its own prompt), but we need some way to communicate with the process after it's started.
The CRA "test" script, by default, runs in "watch" mode, which means you can enter commands to rerun part of all of the tests. I'd love a future where we have a powerful, easy-to-use module that allows for precise test control, but this requires being able to send arbitrary commands at arbitrary times to the running process
This has been surprisingly hard to solve for me, due to some issues with Electron. The standard approach is to use childProcess.fork
; I ran into some issues when trying to use it though (unfortunately I don't remember what they were D:)
We're currently hacking around this in task.middleware.js
by simply pre-emptively supplying the command with the pipe operator:
const command =
project.type === 'create-react-app' && name === 'eject'
? 'echo yes | npm'
: 'npm';
This is clearly a hack, and it's problematic because it doesn't scale. It would be great to have proper bi-directional communication, for the reasons mentioned above.
This is also a problem because Windows doesn't support echo
.
I'd say this is probably the biggest priority issue (as it's blocking Windows support, which is extremely important). If anyone wants to help solve this, I would super duper appreciate it!!
Describe the bug
Project list disappear after re-open
To Reproduce
Expected behavior
Can see project list after re-open Guppy
Screenshots
Environment (please complete the following information):
Additional context
I download from tag v0.1.0, but Finder show the version of Guppy is 0.0.1.
It'd be cool if after building your Gatsby or CRA site, you could then preview the built site via Gatsby's built-in serving and a standalone server for CRA.
When I created tasks.reducer.js
, I wanted to keep a 'flat' structure; every task was given an ID of the form projectId-taskId
, and it was 1 level deep:
{
foo-start: { ... },
foo-build: { ... },
bar-start: { ... },
bar-build: { ... },
}
This wound up requiring a fair amount of munging, and it felt like a bit of extra friction whenever I needed to read/write tasks.
When I tackled the dependencies reducer, I decided to experiment with a nested structure. So instead, each project has its own key:
{
foo: {
start: { ... },
build: { ... },
}
bar: {
start: { ... },
build: { ... },
}
}
This structure actually works quite a bit better, because no dynamic string creation is required.
However, now there's this really irksome inconsistency between two database-style reducers. It would be great to update tasks.reducer.js
to match dependencies.reducer.js
I see a few parts to this refactor:
tasks.reducer.js
to use the new formattaskId
, but they'd need to now take projectId
and taskName
Task
type to remove taskId
; that doesn't exist anymoretaskId
getInitialState
in redux-persistence.service.js
to use the new structureThis is indeed a pretty big job, but it'll only get bigger as the app grows, so I think it'd be great to get this done sooner rather than later.
Is your feature request related to a problem? Please describe.
In a team, a tool like Guppy are not everyone's favorite to use. So this is not a mandatory tool.
If the configuration of Guppy is in package.json
, It's hard to ignore this non-essential configuration
Describe the solution you'd like
Provide a additional configuration file or folder, just like yarn.lock
, babel.lrc
, .vscode
, .idea
.
Describe alternatives you've considered
package.json
Additional context
Right now, Guppy has no auto-update mechanism. This means that when we release a new version, the people using Guppy have to come back to this repo to download and install it! This is lame.
Auto-update appears to come built-into electron-builder. It also comes with other benefits, like building a .dmg
for installation.
Unless anyone has any better ideas, I think we should switch to electron-builder.
I've been delighted to see how many devs are excited about Guppy; having so many contributors working towards building something great is really amazing :)
I haven't really seen much feedback from the "core" audience, though. It's unclear to me how well Guppy works for beginners.
Guppy isn't yet ready for primetime; there are still some bugs, some basic missing functionality, and nowhere near enough docs. But I wonder if there are ways to help guide our development by doing small tests with beginners. It might really help inform our decisions to understand the pain points. Could affect how we prioritize features!
The trouble is, my network is largely experienced developers. I don't know how to find beginners.
This issue is a discussion to see how we might start collecting feedback from newcomers. If any of y'all have friends/family that are looking to get into web development, that could be a good place to start!
Describe the bug
Process started by Guppy after reload or exist.
These processes are still alive in the background.
To Reproduce
Expected behavior
Close all processes started by Guppy after shutdown Guppy
Screenshots
Environment (please complete the following information):
Additional context
This is a desktop app, and desktop apps don't have the "no sounds!" stigma that the web has.
Some ideas:
I should be able to use redux-sounds
to have this tie-in effortlessly with Redux.
Guppy's goal is to remove barriers for beginners to learn how to do modern web development. One huge barrier is that tools like create-react-app are only available in English, and many aspiring web developers don't speak English!
It would be awesome to get i18n support in Guppy. Unfortunately, it's also a huge amount of effort, and not one I foresee having time to develop. If folks are interested in contributing, the first step is to add i18n support to the application. One upside to building a desktop app is that small sizes aren't so critical, so we could probably get away with a pretty minimal solution:
/copy/en.js
or similarCurrent status (WIP see branch feature-i18n
)
Currently, to keep things simple, Guppy just uses the system NPM to install dependencies.
It would be great to find a more efficient solution, though. I have my eye on pnpm
(https://github.com/pnpm/pnpm), a manager that helps avoid the bloat of new projects having several hundred MB in node_modules
. Especially for aspiring developers who may be on lower-end machines with less total disk space, being able to significantly shrink the size of having multiple projects seems like a huge win, and I imagine the installation speed would go way up as well!
Firstly.. Gorgeous app, loved the onboarding and the sleek ui.. Nice work..I was wondering if you could add an option for configuring project path to save guppy projects at onboarding else use the default path. Also once the project is created you should specify the folder path. Alternatively you could also give a button saying. Open in VScode or some editor..
I had to run the dev server to know the folder path, but again i think this is a fantastic app.. Kudos.
h2|h*
to source readme.md
here is UI
## People of World
- [![china](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/China.png) **中文/Chinese**](https://github.com/chinanf-boy/guppy-docs-zh)
that docs of translate chinese with git source commit https://github.com/joshwcomeau/guppy/tree/73a9f68702d44fe03dad118bd1b112f1998ef454
Suggestion: it would be nice to give a choice of starters to allow users to bootstrap more complete projects using the GUI.
A first version could just include a choice between different Gatsby starters
Eventually, a more complete solution could allow for more customization using an Ignite boilerplate/plugin (will soon support both React & React Native). For example:
Would you like to statically type your code?
Which of these would you like to use for static typing?
This might be out of scope for this project though.
While using Guppy, I noticed that a couple things made it less-than-ideal:
We should have a "fullscreen" button which makes the terminal take up the whole window.
We can also add a "clear" button. This'll become less critical once we have #36, but it's always good to have the ability to clear the terminal. Could even use the cmd + k
shortcut that standard terminals use.
Guppy currently only works on MacOS. Let's fix that and make it Windows-friendly!
Note: This ticket is blocked by a couple of others that should probably be tackled first. See below:
Some notes:
Guppy does a lot of filesystem stuff, and it's unclear to me how much work is required for Windows compatibility.
All projects are currently created in {os.homeDir()}/guppy-projects
. Does this still make sense on Windows?
This ticket is blocked by #25, because we're currently hacking around an issue by using echo
, which isn't supported on Windows.
This ticket is also sorta blocked by #26 - if we're gonna switch to electron-builder, we should do that before spending time/energy on a windows installer solution.
By default, the terminal output viewers just pass along whatever the underlying tools spit out.
Sometimes, this output is not helpful for Guppy. For example, Gatsby instructs to run yarn build
in the dev server output. There's no way to run terminal commands, and so it's irrelevant.
In an ideal world, I think we'd transform existing output into something friendlier / more appropriate... but there are some issues with this approach:
Given those issues, maybe a simpler thing is to target specific substrings. We can just have an i18n-style map of "if you see X, replace it with Y". Otherwise, it should do nothing. This still has some maintenance cost, but the worst case is that we don't transform an irrelevant instruction, which is exactly where we are today, so I think that's OK!
Trying to get this set up locally on my machine. Per the CONTRIBUTING.md I have:
npm install
(this wasn't in the instructions but assumed I needed to do this)npm run start
- this is where the error is thrown, and then process hangsNpm v6.2.0
Node v9.6.1
Considering it doesn't seem like anyone else has run into this, I would assume it's something to do with my particular setup, but I can't pinpoint what. Feel free to point me somewhere else if this doesn't belong here...
After ejecting a CRA app user have to install the required dependencies before running the app again. This is leading an error in development server after ejecting the app.
It would be a good UX if a warning shows up after ejecting, telling to run command npm install
or maybe event better to run the command right after eject task finishes without prompting anything.
As mentioned in #28 it would be great to have typed Redux actions and I think src/actions/index.js
could be refactored as well. We'd like to do this in a separate PR to change everything at once.
I'd separate each related action into it's own file and export just the type Action
from src/actions/index.js
.
export const SAVE_PROJECT_SETTINGS_START = 'SAVE_PROJECT_SETTINGS_START';
export const SAVE_PROJECT_SETTINGS_ERROR = 'SAVE_PROJECT_SETTINGS_ERROR';
export const SAVE_PROJECT_SETTINGS_FINISH = 'SAVE_PROJECT_SETTINGS_FINISH';
export type saveProjectSettingsAction = {
type: SAVE_PROJECT_SETTINGS_START,
project: Project,
};
export type doneProjectSettingsAction = {
type: SAVE_PROJECT_SETTINGS_FINISH,
project: Project,
};
export type ProjectAction =
| saveProjectSettingsAction
| doneProjectSettingsAction;
export const doneProjectSettings: doneProjectSettingsAction = (project: Project) => ({
type: SAVE_PROJECT_SETTINGS_FINISH ,
project
});
export type { ProjectAction } from './project.actions.js';
export type { DependencyAction } from './dependency.actions.js';
project.middleware.js
:import type { ProjectAction } from '../actions';
import { SAVE_PROJECT_SETTINGS_START, doneProjectSettings } from '../actions/project.actions'
export default (store: any) => (next: any) => (action: ProjectAction) => {
switch(action.type) {
case SAVE_PROJECT_SETTINGS_START:
// rename folder
// change project name & icon in package.json
// once resolved...
store.dispatch(doneProjectSettings(action.project));
break;
}
return next(action);
}
src/actions/index.js
? Just the types or anything else?src/actions/index.js
is hard to maintain and difficult to add new actions.dependency.actions.js
projects.actions.js
(addProject, refreshProjects, selectProject, createNewProject, ... )task.actions.js
modal.actions.js
I tried importing an old side project just to see how the application works etc. As this was not created with Gatsby, create-react-app then this failed and gave the warning message as expected. However this then resulted in a blank screen and I had to close and reopen Guppy.
Should this not fail gracefully and go back to the initial start screen?
I think next.js can be really good addition to this program since it also supports creating projects with npx
or yarn create
with lots of example projects.
For someone just started using React, setting up SSR can be really confusing so next.js's out of the box support can be really helpful to get things started.
I already read about the possible addition on "How it works" part of the readme but thought it might benefit from getting its own issue to track down and discuss.
I would very much like to work on this but since I don't have a MacOS system I might not be able to test anything. Other than that if someone has any ideas on me how to contribute I am open for suggestions.
Thank you for the great project.
Gorgeous app! Was really fun playing around with it a bit tonight.
I did manage to cause a build failure on accident. I added a new dependency (super nice) and while it was installing, somewhat absent-mindedly started a build which then failed of course because some of the dependencies had been deleted or moved around or whatever due to the ongoing install.
It obviously makes sense for long-running operations to be a toggle e.g. starting the develop server. But perhaps builds/format/tests/etc should be buttons since they're discrete tasks which then finish?
Feature to search dependencies with a text input box.
Scrolling huge list of dependencies is difficult.
Would Love and Look forward to contributing by adding this feature. Thoughts...
Right now, installing Guppy is a 2-step process:
Guppy is an electron app, though, and electron apps come with a built-in Node runtime! How cool would it be to no longer require a Node installation, by just using the bundled one if no system Node is found.
(I think we'd still want to use the system Node, when it's available, so that there's no difference between running scripts in a terminal vs. Guppy. But for the true beginner without Node, they shouldn't need to first worry about getting Node set up!)
If this proves to be challenging, we should at least prompt the user in-app to download Node if it isn't found (right now creating a project just fails mysteriously :/)
Right now, there's no way to create new tasks through the UI. You have to modify the package.json and then reload Guppy.
This task has a few parts:
guppy
key on package.json
)new-component -t functional [ComponentName]
. It'd be great to find a way to allow the user to enter variables when running tasks, when necessary. That said, this is a big task in itself, and should probably be dealt with separately. Just good to keep in mind.Hi! II'm trying guppy in my macbook with macOs Mojave and I have a problem with the colors of the app, because I imagine that the fact of having active the darkmode that makes the default font is white looks like this:
This is not absolutely important but damages the first impression when trying to use guppy.
Most of the popular IDEs (VS Code, Atom, Webstrom etc.) give some sort of git support out of the box or with a plugin or extension. These help you to quickly perform git task like pull, push, sync etc.. Although these are really helpful they are not really informative. Github Desktop app supports a GUI that can help you to ditch terminal/command line usage for these task but since it is really detailed I'm not sure if a just started user would use it.
For someone just started learning code, git can be scary since it has its own terminology and way of thinking. Since Guppy targets new users, it might be beneficial to add some level of git support with some descriptions about what does that task do underneath.
What can be added?
I think adding "Import with git URL" option can be a good start. This option can be used to add great boilerplates to Guppy without need to first clone the project and then importing it to the Guppy.
This addition would bring up some more things to the table though. We are currently setting up task bar with default tasks. Maybe we should scan the package.json/scripts
and add those task too?
I'm really curious on your thoughts about this.
Installing or updating dependencies is quite slow: npm install --save some-dep
might take 30-40+ seconds, even on a really fast computer.
Worse, they can't easily be parallelized. For example, you can't run npm install --save some-dep
and then, 2 seconds later in another terminal tab, run npm uninstall some-other-dep
.
The reason for this is that both of these commands modify package.json
, and NPM is smart enough to "lock" write access to the file while operations are in progress (otherwise, uninstalling the dependency might accidentally undo the first command).
In a terminal, this can be mitigated by batching commands, either by installing multiple things at once (npm install --save some-dep some-new-dep
), or by chaining in the same command (npm install --save some-dep && npm uninstall some-other-dep
).
In Guppy, every dependency has to be installed one at a time, and there's no way to "queue" actions. When you install a dependency right now, all other dependency actions are greyed-out until it completes. This means that adding 5 dependencies is super painful, and easily the worst UX I've discovered so far with Guppy.
While we can't break the rules of running multiple commands at once, we can create our own queue system. If the person wants to install 5 dependencies, they should just be able to click "add to project" to 5 dependencies in quick succession, and Guppy should have some UI that shows the current status on those actions, without blocking them from other stuff like running tasks.
I imagine having a toast in the top-right corner that shows which step it's currently on, and how many steps are left.
We could also try and optimize this queue. For example, when the person tries to install 4 dependencies, the 1st one will start right away... but we can then group dependencies 2, 3, and 4 into a single command, to speed things along.
The MVP version of this issue, though, is probably just to add functionality to the task reducer and middleware that handles this queue, and some basic UI to show that something is in-progress. If we discover that there's additional complexity with different action types, we can limit it just to adding or removing (eg. you can add as many dependencies as you want, but if you then try to remove a dependency, a prompt tells you to wait until all dependencies have been added before removing. And vice versa)
We have a pretty good collection of reusable components in this project, but they're not discoverable!
We should use React Storybook to showcase the reusable "building-block" components we have, so that developers can quickly browse a catalog of available options. This way, we reduce the chance that a developer might spend time re-implementing something unnecessarily.
@AWolf81 has graciously taken on the task of getting the project set up, which is no small feat due to a Babel issue + the fact that we haven't yet had to worry about browser support (Electron bundles its own Chromium, but with Storybook we need to make sure these components work with Firefox/Safari).
I believe @AWolf81 has almost completed that work, so this is mostly a retroactive issue to help highlight progress for anyone else curious.
After cloning the repository and attempting to run npm install
, I get the following error:
$ npm i
npm ERR! code ETARGET
npm ERR! notarget No matching version found for acorn-globals@undefined
npm ERR! notarget In most cases you or one of your dependencies are requesting
npm ERR! notarget a package version that doesn't exist.
npm ERR! A complete log of this run can be found in:
npm ERR! C:\Users\super\AppData\Roaming\npm-cache\_logs\2018-07-17T14_11_54_838Z-debug.log
This error appears to be due to a corrupted package-lock.json. The offending line can be found here, in the dependencies for jest-environment-jsdom
:
# line 8557
"jest-environment-jsdom": {
"version": "22.4.3",
"resolved": "https://registry.npmjs.org/jest-environment-jsdom/-/jest-environment-jsdom-22.4.3.tgz",
"integrity": "sha512-FviwfR+VyT3Datf13+ULjIMO5CSeajlayhhYQwpzgunswoaLIPutdbrnfUHEMyJCwvqQFaVtTmn9+Y8WCt6n1w==",
"dev": true,
"requires": {
"jest-mock": "^22.4.3",
"jest-util": "^22.4.3",
"jsdom": "^11.5.1"
},
"dependencies": {
---> "acorn-globals": {},
"jsdom": {
"version": "11.11.0",
"resolved": "https://registry.npmjs.org/jsdom/-/jsdom-11.11.0.tgz",
"integrity": "sha512-ou1VyfjwsSuWkudGxb03FotDajxAto6USAlmMZjE2lc0jCznt7sBWkhfRBRaWwbnmDqdMSTKTLT5d9sBFkkM7A==",
"dev": true,
Deleting package-lock.json allows for a successful install.
So long as guppy doesn't require a specific version of any recently updated packages, it should be safe to delete this file and let Node regenerate it on the next commit.
At the moment, I'm trying to fix eject
project for Windows support and create many projects for testing eject - maybe I have to look for another way to debug stdin.write
.
Then I noticed that we need to have a way to handle many projects in the sidebar.
Here is how it looks (last project icon not displayed & add new button off screen in sidebar):
There are multiple solutions we could use to fix it:
I'd prefer the show more option & limit the projects to 5 and then display show more button so the user can trigger a popover/modal to show all other projects.
I think this is not super important because with normal usage it probably takes some time to have more than 10 projects.
So I just noticed this weird 'bug' (is it a bug?) in the Dependencies box, prompted from the discussion from #87 (about splitting up deps and dev deps).
Describe the bug
If you create a new Gatsby project, the resulting package.json
has 4 dependencies and 1 dev dependency (Prettier). Right after installation, in the Dependencies box, only the 4 deps are shown, and Prettier is not shown. Weird.
However, you can then do a search for Prettier and the result allows you to install it again (shows the button 'Add to Project' instead of 'Installed').
If you then go and install it again to the project, it updates the version in package.json
and it then registers that it was officially added (so the button is changed to 'Installed') and it gets added into the Dependencies list.
To Reproduce
Expected behavior
All deps and dev deps are shown in the Dependencies list from the start, and the package should show 'Installed' in its search result.
Screenshots
Environment (please complete the following information):
Additional context
This is not specific to Gatsby projects, it also persists if you import any existing project with dev dependencies.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.