Myrne Stol
Myrne Stol
Some of original code gave warnings but did not fix. For example, the various typos that were defined. Other parts corrects things silently. For example (from original). ``` javascript function...
Currently, the code corrects known fields, but leaves unknown fields alone. Is it a goal to give people the ability to put arbitrary fields in package.json?
In original async code, callback was immediately called with an error object ``` javascript var ret = validName(file, data) if (ret !== true) return cb(ret); ret = validVersion(file, data) if...
Original code: ``` javascript function validName (file, data) { if (!data.name) { data.name = "" return true } // some more stuff } ``` Perhaps in the whole npm flow,...
The original code only warns about typos. When consuming package data in npm-www for example, it may be desirable to actually fix the (known) typos. On the other hand, this...
Originally, I thought that it would be best to separate the code for generating warnings from the code that make changes to data. But that was before I thought of...
For example, the code currently sets the "_id" field. A concatenation of name and version. It also adds all optional dependencies to dependencies. I have no experience with the "semantics"...
Currently, there's a local "fixer.js" containing the value-inference code. If this was put in a separate module, other interfaces to this code could be written. Normalization of all package data...
1. Remove it always. 2. Remove it if neither valid url or email were given, or could have been inferred. (current behavior) 3. Set it to an empty object. 4....
Not guaranteed to be array: keywords, contributors, authors, man. Guaranteed to be array (if set): files