Comments (5)
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"
]
}
from normalize-pkg.
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.
from normalize-pkg.
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.
from normalize-pkg.
sorry for writing War and Peace, Part II. lol
from normalize-pkg.
Closing since normalize-pkg
will fill in smart defaults for missing fields.
from normalize-pkg.
Related Issues (12)
- find an API or site that provides JSON for licenses HOT 3
- store common, generic config values HOT 1
- move the CLI into a yeoman generator HOT 1
- Support for repo shorthand syntax HOT 3
- repository normalizer HOT 1
- Add a trailing newline when rewriting package.json file
- author fields not being parsed correctly HOT 5
- Search for local LICENSE file? HOT 1
- try to extract bug url from repository HOT 5
- try to extract homepage url from repository HOT 6
- Integrate package.json validator output? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from normalize-pkg.