Skip to content
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

Open
pkieltyka opened this issue Nov 7, 2017 · 4 comments
Open

package.json naming choice #145

pkieltyka opened this issue Nov 7, 2017 · 4 comments

Comments

@pkieltyka
Copy link

Hello,

Nice project - but would you reconsider renaming the package.json file to something like deps.json ? this conflicts with node's package management

Also, 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

@victorb
Copy link

victorb commented Nov 7, 2017

For the aside, check out this issue: #141

@sterpe
Copy link

sterpe commented Nov 8, 2017

We had some discussions several years ago about trying to make it that a singlepackage.json could serve both gx and npm/yarn/ied: ensuring that same-name fields expressed the same thing and the same shape, which was a little bit complicated by json marshalling/unmarshalling in go.

@pkieltyka
Copy link
Author

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.

@whyrusleeping
Copy link
Owner

having a universal package.json file that support many package managers across ecosystems

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants