Closed ivard closed 4 years ago
Ook even cc @confiks
Qua package-lock files zit er nu geen consistente lijn in. Nu hebben sommige packages wel een package.lock en sommige niet. We moeten ze dan dus of overal wel neerzetten of overal niet denk ik.
@Timendus That seems like a good balance between offering prebuilt files that can be used in projects without a packager, and not creating a service we have to maintain that users depend on.
package-lock.json
(or yarn.lock
) is not used by dependents of these packages, so its inclusion seems questionable to me. However, the Yarn people have a pretty strong opinion on this, so I'd say we include it for every project.
Ik had nu de packages die daadwerkelijk iets builden een package-lock.json
gegeven, en de packages die alleen maar pure Javascript zijn niet. De reden om die file te committen is dat een andere developer daarmee de volgende keer exact dezelfde dist files kan builden, anders krijg je toch verschillen in output door verschillende versies van dependencies. Dat was de afweging die ik had gemaakt, en volgens mij is die nog steeds valide, ook als je de dist files niet commit.
Overal lock files toevoegen lijkt me prima, maar niet echt noodzakelijk.
Considered all remarks, I remained the package-lock.json
in the directories that compile to a dist packages and did not add one in the directories that have no building step. That was indeed a bit superfluous. Therefore the only thing that remains is removing the dist files.
The dist files can be downloaded eventually via npm or maybe we gonna host them somewhere else too.