dapphub / dpack

simple lockfile for your dapp's addresses and artifacts
46 stars 9 forks source link

checklist issue for dpack-1 validation conditions #31

Open nmushegian opened 2 years ago

nmushegian commented 2 years ago

isValidType and isValidObject

isValidPack

sambacha commented 2 years ago

should there also by a version component to the validation?

sambacha commented 2 years ago

Just to clarify, i am not referring to format/dpack-1 rather a versioning scheme that takes into account direct dependencies of the project (namely typescript and ethers).

nmushegian commented 2 years ago

This issue is for defining well-formed dpack-1 files, for versioning issues related to this particular javascript dpack library please open a separate issue

sambacha commented 2 years ago

This issue is for defining well-formed dpack-1 files, for versioning issues related to this particular javascript dpack library please open a separate issue

@nmushegian ahh I was inferring from isValidPack to imply that this dpack is usable whereas it is more so this dpack is compliant with the specification, i.e. maybe isCompliantPack may be less ambiguous as to its value of measurement. apologies.

Can we separate out the schema from the current definition location to its own json schema file? we can use regex (patterns in json schema format) to validate + can be listed on https://www.schemastore.org/json/

Here is an example (note this is not actually a proper json schema file just quick example): https://github.com/sambacha/dpack/blob/93cc887459cd3d8dd5b3a63f8958531e19e3995d/spec/dpack-1.schema.json

regex patterns for validation of address and bytecode are provided. Using patterns can do all off the items in isValidType and isValidObject

nmushegian commented 2 years ago

To avoid confusion I think we might just remove schemas altogether and validate each possible error case directly, since a proper spec needs distinct error codes anyway

I think I will use isWellFormed everywhere since that is all that the dpack-1 spec actually is

sambacha commented 2 years ago

To avoid confusion I think we might just remove schemas altogether and validate each possible error case directly, since a proper spec needs distinct error codes anyway

I think I will use isWellFormed everywhere since that is all that the dpack-1 spec actually is

this sounds much better