[QUESTION] How "verbose" should the normalized version be?
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- javascript
- Ambito
- tooling
Direzione di ricerca
Start by reviewing the normalization code and the current handling of the _id field, optional dependencies, and people fields described in the issue. Done requires a decided definition of the normalized form, including whether it should prioritize machine consumption, human readability, or separate representations.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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" of optional dependencies, but it's certainly verbose.
People fields (author and such) are expanded to {name,email,url} objects. Handy when coding, but maybe less appropriate as a canonical version.
Normalization code like this might have two actually use cases: One for easy consumption by computers, one for fixing a human's mistake, but keeping the JSON somewhat humane.
- Lingua principale
- JavaScript
- Stelle
- 204
- Fork
- 54
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di npm/normalize-package-data
-
[BUG] Array dependencies can't handle scoped packagesForse già presa @vhinayindia l’ha presa 13 giorni fa. Apertabug
Difficoltà 2/5 1-3 ore Idoneità per principianti 45/100
npm/normalize-package-data#105 ·
-
feature
Difficoltà 4/5 3-5 giorni Idoneità per principianti 32/100
-
bug
Difficoltà 3/5 1-2 giorni Idoneità per principianti 25/100
-
feature
Difficoltà 3/5 1-2 giorni Idoneità per principianti 35/100
npm/normalize-package-data#83 · 1 commento ·
-
[BUG] Just because a package has a preinstall doesn't mean it doesn't have a gypfileForse di nuovo libera Una pull request per questa issue è stata chiusa senza essere unita. Apertabug
Difficoltà 3/5 1-2 giorni Idoneità per principianti 35/100
npm/normalize-package-data#75 · 2 reazioni ·
Tutte le issue di npm/normalize-package-data
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 2 giorni
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
swc-project/swc-next#1022 ·
I maintainer di solito rispondono entro 1 giorno
-
area-clientside-dartpad
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
alphagov/public-asset-checker#378 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
headers-parser: `forRegExp` does not escape regexp characters in path segments that contain `*`Forse già presa @RaphaelFakhri l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
I maintainer di solito rispondono entro 1 giorno