Length parameter for string values in schema

[burhan85]

I have modified the parser for this requirement for my own use, but an official change for a length parameter defined in the schema options would be very helpful.

[catamphetamine]

You mean, setting maxLength: number?
That would be too specific, I guess.
Though, an API could provide something like "custom types": maybe something like type: LimitedString where LimitedString would be an object providing type/parse and validate properties.

[burhan85]

Yes, I mean providing a validation property for length in schema definition like
'Distributor Code': { prop: 'BuyerCode', type: String, maxLength: 45, required: true }
I had modified the js to validate the length but then went for a workaround by using 'parse'.
'Distributor Code': { prop: 'BuyerCode', type: String, required: true, parse(value) { if (value.length > 45) throw new Error('Distributor Code exceeds maximum length of 45 characters.'); else return value; } }
I don't get what you mean by being it too specific because it is kind of a basic thing to have a min/max length validation for strings and min/max value validation for numbers/dates. But yeah, I suppose, since this package is only for reading excel files so it might be an overkill to have too many validations.

[catamphetamine]

I don't get what you mean by being it too specific because it is kind of a basic thing to have a min/max length validation for strings and min/max value validation for numbers/dates. But yeah, I suppose, since this package is only for reading excel files so it might be an overkill to have too many validations.

Yeah, this package should not re-invent advanced validation: there already are things like yup for that. This package could support passing some kind of a validationSchema property that could be a yup schema, but then it would have to use it both for validation and parsing, and the original schema would only contain the prop property then, because other properties would be already contained in a yup schema, so the original schema could be simplified to something like { 'COLUMN_HEADER': 'propertyName', ... }, and it wouldn't be called a "schema" then, it would be called something like mapping, and schema would be the yup schema.

But I wouldn't implement something like that because that would be too much work.
Alternatively, this library could support the mapping property defined above, that would be an alternative to a basic schema with props and type: String for all props. Then, a developer could pass the output to something like yup for the actual parsing and validation.

[catamphetamine]

In version 4.1.0, a map parameter has been added: similar to schema but doesn't perform parsing or validation.
https://github.com/catamphetamine/read-excel-file#map