module, like, goes crazy on empty package.json

[jonschlinkert]

module, like, goes crazy on empty package.json

[pdehaan]

For argument sake, here's the output from my empty ({}) package.json file:

{
  "valid": false,
  "errors": [
    "Missing required field: name",
    "Missing required field: version",
    "Missing required field: author"
  ],
  "warnings": [
    "Missing recommended field: description",
    "Missing recommended field: keywords",
    "Missing recommended field: bugs",
    "Missing recommended field: licenses",
    "Missing recommended field: contributors",
    "Missing recommended field: repository"
  ],
  "recommendations": [
    "Missing optional field: homepage",
    "Missing optional field: dependencies",
    "Missing optional field: engines"
  ]
}

[pdehaan]

Anyways, not sure what I'm complaining about here actually. My guess would be if there is no "author" field originally, should you create one, and have it invalid? Or just skip it and not add it. Is it better to be invalid and have an empty author field (which I could then quickly fill in manually), or be invalid and have a missing author field.

[jonschlinkert]

Regarding the question of whether or not we should skip a field and leave it invalid vs. create an empty one and leave it invalid, I consciously chose the latter. The reason is that, IMO all thing being equal, both decisions lead to a technically invalid result, but creating the field instead of skipping does a couple things: 1) it reminds you that it ought to be filled out, since it's technically invalid to not have the field at all (out of sight, out of mind), 2) other libs that consume and use package.json files can use this library and not have to worry about creating additional logic in their own libs based on whether or not these fields will be present. This doesn't prevent libs from checking for empty fields, so it's easy to work around.

On that same note, I'm glad you brought this up bc/ I think we should add basic logic to add all missing fields. We can also consider adding "modes", based on what would be expected by one spec versus another.

This is conjecture, but it really seems that some of the fields that are "recommended" and "valid" as strings ought to be objects in the real world. Anecdotally, I've noticed that some systems including npm itself tend to prefer objects, and providing inconsistent results based on whether a field is a string or an object. specifically, I've noticed when browsing npm that when certain fields are formatted as objects npm will yield the correct data, but fields are strings sometimes links are missing, etc. My guess is that even though npm checks for both the string and object versions (and sometimes array), when you fill out the author field like this for example: Peter deHaan <[email protected]> (http://nodeexamples.com/), there is more likely to be a user error that results in a parsing error - despite the fact that you used the correct type. But again, anecdotal.

[jonschlinkert]

sorry for writing War and Peace, Part II. lol

[doowb]

Closing since normalize-pkg will fill in smart defaults for missing fields.