-
Notifications
You must be signed in to change notification settings - Fork 110
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
package.json naming choice #145
Comments
For the aside, check out this issue: #141 |
We had some discussions several years ago about trying to make it that a single |
having a universal package.json file that support many package managers across ecosystems sounds too ambitious of a project that will lead to complexity and in the end will stall mid-progress, just my 2 cents. Keep the intentions/goals clear, direct and simple - thereby the design will be so as well, and so will understanding of the system. |
the idea wasnt to have a package.json that supports everything, but for the gx package.json to not interfere with node. This may no longer be the case, but at one point I made it so that any shared fields had the same types, and any fields unique to gx were kept separate, and gx wouldnt touch any node fields. That doesnt seem too ambitious to me, and keeping a lot of copied state in two different package files seems like the more complex solution. |
Hello,
Nice project - but would you reconsider renaming the
package.json
file to something likedeps.json
? this conflicts with node's package managementAlso, an asdie: for go package management, have you considered augmenting https://github.com/golang/dep to add support for IPFS to make it content-routing aware? I presume gx started before golang/dep
The text was updated successfully, but these errors were encountered: