Open nmushegian opened 2 years ago
should there also by a version component to the validation?
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).
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
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
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
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
isValidType and isValidObject
types
objects
isValidPack