Not to edit `package.json` when import a existing project

[xyy94813]

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

• Increased the selectivity of guppy in a team
• Will be well managed
• More personalized and flexible
• Reduced conflicts in package.json

Additional context

[joshwcomeau]

Provide a additional configuration file or folder, just like yarn.lock, babel.lrc, .vscode, .idea.

Semantically, I feel like this stuff does belong in package.json.

Guppy's "config" is actually just info about the project; it's descriptive about the app being built. A config file suggests that it's a setting to control the behaviour of the tool, not information about the host project. So it feels weird to me, semantically, to have a .guppyrc or similar.

If one member of a team wants to use Guppy, I agree it's a bit odd that it updates everyone's package.json, but it's also not harmful.. it still doesn't mandate that everyone has to use it, it's easy to ignore. And Guppy isn't really targeted at folks already collaborating with a bunch of experienced developers, it's meant for beginners.

All of that said, I agree that this is controversial. And, while I feel like experienced team members should just get over having some extra metadata in package.json, those experienced team members might not feel the same way, so it might be harder for junior devs to use Guppy. So maybe it does make Guppy harder to adopt, in certain edge-cases.

Curious to hear from others.

[bennygenel]

This was actually something I have been thinking for a while and I think I agree on that Guppy should have its own file. I think Guppy is closer to the IDE category (I'm not saying it is an IDE) and most IDEs has their own directory/file to keep up with the projects (.idea folder, .vscode folder etc.) and these folders usually added to the .gitignore file.

...And Guppy isn't really targeted at folks already collaborating with a bunch of experienced developers, it's meant for beginners.

Might be an edge case but bunch of beginner students can collaborate on a project and while some of them prefer to use Guppy, others might not.

With all this in mind, future improvements might bring some more fields to the config.

[joshwcomeau]

@bennygenel yeah, I hear what you're saying.

I think if we do create a .guppy directory, folks will add it to .gitignore, and I actually think it'd be better for it to be checked in, for a couple reasons:

• Icon (right now it's kinda random and doesn't matter, but soon users will be able to upload icons, and it'd be great for all Guppy users of the project to have the same experience).
• Task descriptions - eventually I imagine users being able to create their own tasks (AKA NPM scripts), and they'd want to annotate them with a description.
• Future things! It's hard to predict where Guppy will go, but I can imagine a few things that would benefit from being consistent across all Guppy users, and it'll be harder to ensure that if folks have become accustomed to .gitignoring the .guppy dir.

Especially for open-source projects, I imagine it being really helpful if Guppy project metadata came with the repo. Even for a single developer who works on multiple machines, it'd be bad to have an inconsistent experience.

I think this goes back to why I feel like it's not actually a config file, like .vscode - it includes data about the project, not just settings for the tool. If people treat it as a config file, they'll gitignore it, and it'll lead to a worse experience.

But yeah, the truth is I don't feel that strongly about it, and I expect that this issue will continue to crop up. I suspect 90% of devs will agree with you both, and it's not a hill I want to die on, haha. So I'm open to changing it, although I'd love if we took the "Yarn approach" and advocated for leaving it in source-control.

[bennygenel]

@joshwcomeau I agree that if .guppy directory ignored there might be complications but I still think there might be a better solution.

Like you said if we have .guppy direactory because it's a dot directory, it might get ignored but how about using a single JSON file like tsconfig.json. We can have a big comment on top of that file stating that it should be committed to have a better user experience.

Another point I want to add is that, the properties on package.json files are meant to be changeable. Like if I want to install another version of a dependency I can simply edit the version in package.json. I can even create it manually with all the properties I want without using npm init or yarn init command. We can not say the same thing for guppy properties though. If I change the id of the project, there might be some complication or I might end up changing type of the project to something might end up for an error. I know these are edge cases but having some property not changeable or not meant to change in a package.json file seems wrong to me. With this said there might be similar cases that I don't know.

[joshwcomeau]

Like you said if we have .guppy direactory because it's a dot directory, it might get ignored but how about using a single JSON file like tsconfig.json. We can have a big comment on top of that file stating that it should be committed to have a better user experience.

There might be other files as well (if the user selects a custom icon, for example), so I think a directory gives us more flexibility in the future. But maybe we can always add a guppy-assets directory later or something?

It occurs to me that we probably shouldn't make it a dot file (or dot directory), since the whole point of Guppy is to skip having to use the terminal, and so we shouldn't be hiding the files from Finder. I think someone brought this up about the Guppy projects dir, but it's also valid for the guppy config within projects.

Another point I want to add is that, the properties on package.json files are meant to be changeable. Like if I want to install another version of a dependency I can simply edit the version in package.json. I can even create it manually with all the properties I want without using npm init or yarn init command. We can not say the same thing for guppy properties though. If I change the id of the project, there might be some complication or I might end up changing type of the project to something might end up for an error. I know these are edge cases but having some property not changeable or not meant to change in a package.json file seems wrong to me. With this said there might be similar cases that I don't know.

The properties in Guppy are changeable, as long as they're valid. If you want to specify a different icon path, or rename the project, you can do that by modifying the package.json :) I believe Guppy reads the properties from this file on load, so you'd just have to reload Guppy to see the changes. Even if you change the ID, everything should work (it might invalidate the electron store cache, but a big reason to have this stuff in package.json is so that the electron cache can be thrown away, and the essential data can be reconstructed from package.json). If changing the ID causes something in Guppy to break, that's a bug we can fix.

It's true that if you change the project type to something like "nextjs" (which isn't yet supported), things might break, but to me that's the same as things breaking if you enter an invalid version number for a dependency, or use invalid characters in the name field.

But yeah, I don't think we have to spend too much time debating :) I agree that it's a weird thing to be modifying the package.json, so I'm OK with having a config file or directory.