You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To not only contain the package.json information (how to call that? package definition?) but also other working details, like the package directory, that conceptually are very close to the package definition. The question is whether to rename it or extend it in a separate structure.
The text was updated successfully, but these errors were encountered:
The plan (at least the last time I discussed this with Why) was to make gx into a lock file manager and rely on language specific package managers for everything else. This'll give us what we want (dependable package "vendoring" without duplication) without antagonizing the rest of the go world.
Just to clarify, I don't mean including the directory inside the package.json, but some functions I'm seeing in the code carry the Package structure and alongside the string with the path where it's installing it. I wanted to consolidate those two in a coherent structure (that may or may not be Package). That is, I simply plan to restructure some internal parts of the gx/gx-go repos, but most definitely not change API or how it's designed (that's something that should be discussed in the issues you're pointing to).
To not only contain the
package.json
information (how to call that? package definition?) but also other working details, like the package directory, that conceptually are very close to the package definition. The question is whether to rename it or extend it in a separate structure.The text was updated successfully, but these errors were encountered: