read-excel-file 9.0.2 → 9.0.4

package/CHANGELOG.md

@@ -1,51 +1,74 @@
 9.0.0 / 18.04.2026
 ==================
 
-* Refactored `parseData()` function.
-* The result of `parseData()` function is now `{ errors, objects }`. If there're no errors, `errors` will be `undefined`. Otherwise, `errors` will be a non-empty array and `objects` will be `undefined`.
-  * Previously the result of `parseData()` function was `[{ errors, object }, ...]`, i.e. the `errors` were split between each particular data row. Now the `errors` are combined for all data rows. The rationale is that it's simpler to handle the result of the function this way.
-  * Re-added `row: number` property to the `error` object.
-* In a schema, a nested object is now not allowed to be `required: true`. Otherwise, if a nested object was allowed to be `required: true`, a corresponding `"required"` error  would have to include a specific `column` title but a nested object simply doesn't have one.
+* If you were using `parseData()` function:
+  * Rewrote the code of the `parseData()` function and renamed it to `parseSheetData()`.
+  * The result of `parseSheetData()` function is now `{ errors, objects }`. If there're no errors, `errors` will be `undefined`. Otherwise, `errors` will be a non-empty array and `objects` will be `undefined`.
+    * Previously the result of `parseSheetData()` function was `[{ errors, object }, ...]`, i.e. the `errors` were split between each particular data row. Now the `errors` are combined for all data rows. The rationale is that it's simpler to handle the result of the function this way.
+    * Re-added `row: number` property to the `error` object.
+  * Renamed some of the exported TypeScript types:
+    * `ParseDataCustomType` → `ParseSheetDataCustomType`
+    * `ParseDataCustomTypeErrorMessage` → `ParseSheetDataCustomTypeErrorMessage`
+    * `ParseDataCustomTypeErrorReason` → `ParseSheetDataCustomTypeErrorReason`
+    * `ParseDataError` → `ParseSheetDataError`
+    * `ParseDataValueRequiredError` → `ParseSheetDataValueRequiredError`
+    * `ParseDataResult` → `ParseSheetDataResult`
+  * In a `schema`, a nested object could be declared as: `{ required: true/false, schema: { ... } }`. This is still true but the `required` flag is now only allowed to be either `undefined` or `false`, so `true` value is not allowed. The reason is quite simple. If a nested object as a whole is marked as `required: true`, and then it happens to be empty, a `"required"` error should be returned for it. But that error would also have to include a `column` title, and a nested object simply can't be pinned down to a single column in a sheet because it is by definition spread over multiple columns. So instead of marking a nested object as a whole with `required: true`, mark the specific required properties of it.
 
 8.0.0 / 11.03.2026
 ==================
 
-* Renamed the default exported function to a named exported function `readSheet`.
-  * Old: `import readExcelFile from "read-excel-file/browser"`
-  * New: `import { readSheet } from "read-excel-file/browser"`
-  * And same for other exports like `"read-excel-file/node"`, etc.
-* The default exported function now returns all sheets in a form of an array of objects: `[{ name: "Sheet 1", rows: [['a','b','c'],['d','e','f']] }, ...]`.
-* Removed `getSheets: true` parameter. The default exported function now returns all sheets.
-* Removed exported `readSheetNames()` function. The default exported function now returns all sheets.
-* Removed `schema` parameter. Instead, use exported function `parseData(data, schema)` to map data to an array of objects.
-  * Old: `import readExcelFile from "read-excel-file"` and then `const { rows, errors } = await readExcelFile(..., { schema })`
-  * New: `import { readSheet, parseData } from "read-excel-file/browser"` and then `const result = parseData(await readSheet(...), schema)`
-    * The `result` of the function is an array where each element represents a "data row" and has shape `{ object, errors }`.
-      * Depending on whether there were any errors when parsing a given "data row", either `object` or `errors` property will be `undefined`.
-      * The `errors` don't have a `row` property anymore because it could be derived from "data row" number.
-        * In version `9.x`, the `row` property has been re-added, so consider migrating straight to `9.x`.
-      * In version `9.x`, the returned result of `parseData()` has been changed back to `{ errors, objects }`, so consider migrating straight to `9.x`. In that case, if there're no errors, `errors` will be `undefined`; otherwise, `errors` will be a non-empty array and `objects` will be `undefined`.
-* Removed `transformData` parameter because `schema` parameter was removed. A developer could transform the `data` themself and then pass it to `parseData()` function.
-* Removed `isColumnOriented` parameter.
-* Removed `ignoreEmptyRows` parameter. Empty rows somewhere in the middle are not ignored now.
-* Renamed some options that're used when parsing using a `schema`:
-	* `schemaPropertyValueForMissingColumn` → `propertyValueWhenColumnIsMissing`
-	* `schemaPropertyValueForMissingValue` → `propertyValueWhenCellIsEmpty`
-	* `schemaPropertyShouldSkipRequiredValidationForMissingColumn` → (removed)
-	* `getEmptyObjectValue` → `transformEmptyObject`
-    * The leading `.` character is now removed from the `path` parameter.
-	* `getEmptyArrayValue` → `transformEmptyArray`
-    * The leading `.` character is now removed from the `path` parameter.
-* Previously, when parsing comma-separated values, it used to ignore any commas that're surrounded by quotes, similar to how it's done in `.csv` files. Now it no longer does that.
-* Previously, when parsing comma-separated values, it used to allow empty-string elements. Now it no longer does that and such empty-string elements will now result in an error with properties: `{ error: "invalid", reason: "syntax" }`.
-* Previously, when parsing using a schema, it used to force-convert all `type: Date` schema properties from any numeric cell value to a `Date` with a given timestamp. Now it demands the cell values for all such `type: Date` schema properties to already be correctly recognized as `Date`s when they're returned from `readSheet()` or `readExcelFile()` function. And I'd personally assume that in any sane (non-contrived) real-world usage scenario that would be the case, so it doesn't really seem like a "breaking change". And if, for some strange reason, that happens not to be the case, `parseData()` function will throw an error: `not_a_date`.
-* Previously, when parsing using a schema, it used to skip `required` validation for completely-empty rows. It no longer does that.
-* Removed exported function `parseExcelDate()` because there seems to be no need to have it exported.
-* (TypeScript) Renamed exported types:
-  * `Type` → `ParseDataCustomType`
-  * `Error` or `SchemaParseCellValueError` → `ParseDataError`
-  * `CellValueRequiredError` → `ParseDataValueRequiredError`
-  * `ParsedObjectsResult` → `ParseDataResult`
+* If you were using the default exported function:
+  * Renamed the default exported function to a named exported function `readSheet`.
+    * Old: `import readExcelFile from "read-excel-file/browser"`
+    * New: `import { readSheet } from "read-excel-file/browser"`
+    * And same for other exports like `"read-excel-file/node"`, etc.
+  * The default exported function now returns a different kind of result. Specifically, now it returns all available sheets — an array of objects: `[{ sheet: "Sheet 1", data: [['a1','b1','c1'],['a2','b2','c2']] }, ...]`.
+  * The default exported function used to return sheet names when passed `getSheets: true` parameter. Now, instead of that, the default exported function just returns all available sheets, from which one could get the sheet names.
+
+* If you were using `readSheetNames()` function:
+  * Removed exported function `readSheetNames()`. Use the default exported function instead. The default exported function now returns all sheets.
+
+* If you were using `parseExcelDate()` function:
+  * Removed exported function `parseExcelDate()` because there seems to be no need to have it exported.
+
+* If you were using `schema` parameter:
+  * Removed `schema` parameter. Instead, use exported function `parseData(data, schema)` to map data to an array of objects.
+    * Old: `import readXlsxFile from "read-excel-file"` and then `const { rows, errors } = await readXlsxFile(..., { schema })`
+    * New: `import { readSheet, parseData } from "read-excel-file/browser"` and then `const result = parseData(await readSheet(...), schema)`
+      * The `result` of the function is an array where each element represents a "data row" and has shape `{ object, errors }`.
+        * Depending on whether there were any errors when parsing a given "data row", either `object` or `errors` property will be `undefined`.
+        * The `errors` don't have a `row` property anymore because it could be derived from "data row" number.
+          * In version `9.x`, the `row` property has been re-added, so consider migrating straight to `9.x`.
+        * In version `9.x`, the returned result of `parseData()` has been changed back to `{ errors, objects }`, so consider migrating straight to `9.x`. In that case, if there're no errors, `errors` will be `undefined`; otherwise, `errors` will be a non-empty array and `objects` will be `undefined`.
+  * Renamed some `schema`-related parameters:
+    * `schemaPropertyValueForMissingColumn` → `propertyValueWhenColumnIsMissing`
+    * `schemaPropertyValueForMissingValue` → `propertyValueWhenCellIsEmpty`
+    * `schemaPropertyShouldSkipRequiredValidationForMissingColumn` → (removed)
+    * `getEmptyObjectValue` → `transformEmptyObject`
+      * The leading `.` character is now removed from the `path` parameter.
+    * `getEmptyArrayValue` → `transformEmptyArray`
+      * The leading `.` character is now removed from the `path` parameter.
+  * Previously, when using a `schema` to parse comma-separated values, it used to ignore any commas that're surrounded by quotes, similar to how it's done in `.csv` files. Now it no longer does that.
+  * Previously, when using a `schema` to parse comma-separated values, it used to allow empty-string elements. Now it no longer does that and such empty-string elements will now result in an error with properties: `{ error: "invalid", reason: "syntax" }`.
+  * Previously, when using a `schema` to parse `type: Date` properties, it used to support both `Date` objects and numeric timestamps as the input data for the property value. In the latter case, it simply force-converted those numeric timestamps to corresponding `Date` objects. Now `parseData()` function no longer does that, and demands the input data for `type: Date` schema properties to only be `Date` objects, i.e. it shifts the responsibility to interpret date cell values correctly onto `readSheet()` and `readExcelFile()` functions. And I'd personally assume that in any real-world (i.e. non-contrived) scenario those functions would interpret date cell values correctly, so I personally don't consider this a "breaking change". Still, formally, it is a "breaking change" and therefore should be mentioned. So if, for some strange reason, those two functions happen to not recognize a date cell value correctly, `parseData()` function will return an error for such cell: `"not_a_date"`.
+  * Previously, when using a `schema` to parse sheet data, and a given row of data was completely empty, it didn't run any `required` property validations. Now it no longer does that and it will run all `required` property validations regardless of whether it's a completely empty row of data or not.
+
+* If you were using `transformData` parameter:
+  * Removed `transformData` parameter because the `schema` parameter was extracted into a separate function called `parseData()`. Now, if required, a developer could transform the `data` manually and then pass it to `parseData()` function.
+
+* If you were using `isColumnOriented` parameter:
+  * Removed `isColumnOriented` parameter because it seemed to be of no use.
+
+* If you were using `ignoreEmptyRows` parameter:
+  * Removed `ignoreEmptyRows` parameter. Empty rows somewhere in the middle of a sheet are not ignored now. That doesn't concern empty rows at the end of a sheet though — those're still ignored.
+
+* If you were using TypeScript:
+  * Renamed some of the exported types:
+    * `Type` → `ParseDataCustomType`
+    * `Error` or `SchemaParseCellValueError` → `ParseDataError`
+    * `CellValueRequiredError` → `ParseDataValueRequiredError`
+    * `ParsedObjectsResult` → `ParseDataResult`
 
 7.0.1 / 04.03.2026
 ==================

package/README.md

@@ -24,42 +24,57 @@ Also check out [`write-excel-file`](https://www.npmjs.com/package/write-excel-fi
 
 ######
 
-* Renamed the default exported function to a named exported function `readSheet`.
-  * Old: `import readExcelFile from "read-excel-file/browser"`
-  * New: `import { readSheet } from "read-excel-file/browser"`
-  * And same for other exports like `"read-excel-file/node"`, etc.
-* The default exported function now returns all sheets in a form of an array of objects: `[{ sheet: "Sheet 1", data: [['a1','b1','c1'],['a2','b2','c2']] }, ...]`.
-* Removed `getSheets: true` parameter. The default exported function now returns all sheets.
-* Removed exported `readSheetNames()` function. The default exported function now returns all sheets.
-* Removed `schema` parameter. Instead, use exported function `parseData(data, schema)` to map data to an array of objects.
-  * Old: `import readXlsxFile from "read-excel-file"` and then `const { rows, errors } = await readXlsxFile(..., { schema })`
-  * New: `import { readSheet, parseData } from "read-excel-file/browser"` and then `const result = parseData(await readSheet(...), schema)`
-    * The `result` of the function is an array where each element represents a "data row" and has shape `{ object, errors }`.
-      * Depending on whether there were any errors when parsing a given "data row", either `object` or `errors` property will be `undefined`.
-      * The `errors` don't have a `row` property anymore because it could be derived from "data row" number.
-        * In version `9.x`, the `row` property has been re-added, so consider migrating straight to `9.x`.
-      * In version `9.x`, the returned result of `parseData()` has been changed back to `{ errors, objects }`, so consider migrating straight to `9.x`. In that case, if there're no errors, `errors` will be `undefined`; otherwise, `errors` will be a non-empty array and `objects` will be `undefined`.
-* Removed `transformData` parameter because `schema` parameter was removed. A developer could transform the `data` themself and then pass it to `parseData()` function.
-* Removed `isColumnOriented` parameter.
-* Removed `ignoreEmptyRows` parameter. Empty rows somewhere in the middle are not ignored now.
-* Renamed some options that're used when parsing using a `schema`:
-	* `schemaPropertyValueForMissingColumn` → `propertyValueWhenColumnIsMissing`
-	* `schemaPropertyValueForMissingValue` → `propertyValueWhenCellIsEmpty`
-	* `schemaPropertyShouldSkipRequiredValidationForMissingColumn` → (removed)
-	* `getEmptyObjectValue` → `transformEmptyObject`
-    * The leading `.` character is now removed from the `path` parameter.
-	* `getEmptyArrayValue` → `transformEmptyArray`
-    * The leading `.` character is now removed from the `path` parameter.
-* Previously, when parsing comma-separated values, it used to ignore any commas that're surrounded by quotes, similar to how it's done in `.csv` files. Now it no longer does that.
-* Previously, when parsing comma-separated values, it used to allow empty-string elements. Now it no longer does that and such empty-string elements will now result in an error with properties: `{ error: "invalid", reason: "syntax" }`.
-* Previously, when parsing using a schema, it used to force-convert all `type: Date` schema properties from any numeric cell value to a `Date` with a given timestamp. Now it demands the cell values for all such `type: Date` schema properties to already be correctly recognized as `Date`s when they're returned from `readSheet()` or `readExcelFile()` function. And I'd personally assume that in any sane (non-contrived) real-world usage scenario that would be the case, so it doesn't really seem like a "breaking change". And if, for some strange reason, that happens not to be the case, `parseData()` function will throw an error: `not_a_date`.
-* Previously, when parsing using a schema, it used to skip `required` validation for completely-empty rows. It no longer does that.
-* Removed exported function `parseExcelDate()` because there seems to be no need to have it exported.
-* (TypeScript) Renamed exported types:
-  * `Type` → `ParseDataCustomType`
-  * `Error` or `SchemaParseCellValueError` → `ParseDataError`
-  * `CellValueRequiredError` → `ParseDataValueRequiredError`
-  * `ParsedObjectsResult` → `ParseDataResult`
+* If you were using the default exported function:
+  * Renamed the default exported function to a named exported function `readSheet`.
+    * Old: `import readExcelFile from "read-excel-file/browser"`
+    * New: `import { readSheet } from "read-excel-file/browser"`
+    * And same for other exports like `"read-excel-file/node"`, etc.
+  * The default exported function now returns a different kind of result. Specifically, now it returns all available sheets — an array of objects: `[{ sheet: "Sheet 1", data: [['a1','b1','c1'],['a2','b2','c2']] }, ...]`.
+  * The default exported function used to return sheet names when passed `getSheets: true` parameter. Now, instead of that, the default exported function just returns all available sheets, from which one could get the sheet names.
+
+* If you were using `readSheetNames()` function:
+  * Removed exported function `readSheetNames()`. Use the default exported function instead. The default exported function now returns all sheets.
+
+* If you were using `parseExcelDate()` function:
+  * Removed exported function `parseExcelDate()` because there seems to be no need to have it exported.
+
+* If you were using `schema` parameter:
+  * Removed `schema` parameter. Instead, use exported function `parseData(data, schema)` to map data to an array of objects.
+    * Old: `import readXlsxFile from "read-excel-file"` and then `const { rows, errors } = await readXlsxFile(..., { schema })`
+    * New: `import { readSheet, parseData } from "read-excel-file/browser"` and then `const result = parseData(await readSheet(...), schema)`
+      * The `result` of the function is an array where each element represents a "data row" and has shape `{ object, errors }`.
+        * Depending on whether there were any errors when parsing a given "data row", either `object` or `errors` property will be `undefined`.
+        * The `errors` don't have a `row` property anymore because it could be derived from "data row" number.
+          * In version `9.x`, the `row` property has been re-added, so consider migrating straight to `9.x`.
+        * In version `9.x`, the returned result of `parseData()` has been changed back to `{ errors, objects }`, so consider migrating straight to `9.x`. In that case, if there're no errors, `errors` will be `undefined`; otherwise, `errors` will be a non-empty array and `objects` will be `undefined`.
+  * Renamed some `schema`-related parameters:
+    * `schemaPropertyValueForMissingColumn` → `propertyValueWhenColumnIsMissing`
+    * `schemaPropertyValueForMissingValue` → `propertyValueWhenCellIsEmpty`
+    * `schemaPropertyShouldSkipRequiredValidationForMissingColumn` → (removed)
+    * `getEmptyObjectValue` → `transformEmptyObject`
+      * The leading `.` character is now removed from the `path` parameter.
+    * `getEmptyArrayValue` → `transformEmptyArray`
+      * The leading `.` character is now removed from the `path` parameter.
+  * Previously, when using a `schema` to parse comma-separated values, it used to ignore any commas that're surrounded by quotes, similar to how it's done in `.csv` files. Now it no longer does that.
+  * Previously, when using a `schema` to parse comma-separated values, it used to allow empty-string elements. Now it no longer does that and such empty-string elements will now result in an error with properties: `{ error: "invalid", reason: "syntax" }`.
+  * Previously, when using a `schema` to parse `type: Date` properties, it used to support both `Date` objects and numeric timestamps as the input data for the property value. In the latter case, it simply force-converted those numeric timestamps to corresponding `Date` objects. Now `parseData()` function no longer does that, and demands the input data for `type: Date` schema properties to only be `Date` objects, i.e. it shifts the responsibility to interpret date cell values correctly onto `readSheet()` and `readExcelFile()` functions. And I'd personally assume that in any real-world (i.e. non-contrived) scenario those functions would interpret date cell values correctly, so I personally don't consider this a "breaking change". Still, formally, it is a "breaking change" and therefore should be mentioned. So if, for some strange reason, those two functions happen to not recognize a date cell value correctly, `parseData()` function will return an error for such cell: `"not_a_date"`.
+  * Previously, when using a `schema` to parse sheet data, and a given row of data was completely empty, it didn't run any `required` property validations. Now it no longer does that and it will run all `required` property validations regardless of whether it's a completely empty row of data or not.
+
+* If you were using `transformData` parameter:
+  * Removed `transformData` parameter because the `schema` parameter was extracted into a separate function called `parseData()`. Now, if required, a developer could transform the `data` manually and then pass it to `parseData()` function.
+
+* If you were using `isColumnOriented` parameter:
+  * Removed `isColumnOriented` parameter because it seemed to be of no use.
+
+* If you were using `ignoreEmptyRows` parameter:
+  * Removed `ignoreEmptyRows` parameter. Empty rows somewhere in the middle of a sheet are not ignored now. That doesn't concern empty rows at the end of a sheet though — those're still ignored.
+
+* If you were using TypeScript:
+  * Renamed some of the exported types:
+    * `Type` → `ParseDataCustomType`
+    * `Error` or `SchemaParseCellValueError` → `ParseDataError`
+    * `CellValueRequiredError` → `ParseDataValueRequiredError`
+    * `ParsedObjectsResult` → `ParseDataResult`
 </details>
 
 <details>
@@ -67,11 +82,19 @@ Also check out [`write-excel-file`](https://www.npmjs.com/package/write-excel-fi
 
 ######
 
-* Refactored `parseData()` function.
-* The result of `parseData()` function is now `{ errors, objects }`. If there're no errors, `errors` will be `undefined`. Otherwise, `errors` will be a non-empty array and `objects` will be `undefined`.
-  * Previously the result of `parseData()` function was `[{ errors, object }, ...]`, i.e. the `errors` were split between each particular data row. Now the `errors` are combined for all data rows. The rationale is that it's simpler to handle the result of the function this way.
-  * Re-added `row: number` property to the `error` object.
-* In a schema, a nested object is now not allowed to be `required: true`. Otherwise, if a nested object was allowed to be `required: true`, a corresponding `"required"` error  would have to include a specific `column` title but a nested object simply doesn't have one.
+* If you were using `parseData()` function:
+  * Rewrote the code of the `parseData()` function and renamed it to `parseSheetData()`.
+  * The result of `parseSheetData()` function is now `{ errors, objects }`. If there're no errors, `errors` will be `undefined`. Otherwise, `errors` will be a non-empty array and `objects` will be `undefined`.
+    * Previously the result of `parseSheetData()` function was `[{ errors, object }, ...]`, i.e. the `errors` were split between each particular data row. Now the `errors` are combined for all data rows. The rationale is that it's simpler to handle the result of the function this way.
+    * Re-added `row: number` property to the `error` object.
+  * Renamed some of the exported TypeScript types:
+    * `ParseDataCustomType` → `ParseSheetDataCustomType`
+    * `ParseDataCustomTypeErrorMessage` → `ParseSheetDataCustomTypeErrorMessage`
+    * `ParseDataCustomTypeErrorReason` → `ParseSheetDataCustomTypeErrorReason`
+    * `ParseDataError` → `ParseSheetDataError`
+    * `ParseDataValueRequiredError` → `ParseSheetDataValueRequiredError`
+    * `ParseDataResult` → `ParseSheetDataResult`
+  * In a `schema`, a nested object could be declared as: `{ required: true/false, schema: { ... } }`. This is still true but the `required` flag is now only allowed to be either `undefined` or `false`, so `true` value is not allowed. The reason is quite simple. If a nested object as a whole is marked as `required: true`, and then it happens to be empty, a `"required"` error should be returned for it. But that error would also have to include a `column` title, and a nested object simply can't be pinned down to a single column in a sheet because it is by definition spread over multiple columns. So instead of marking a nested object as a whole with `required: true`, mark the specific required properties of it.
 </details>
 
 ## Install
@@ -84,19 +107,21 @@ Alternatively, it could be included on a web page [directly](#cdn) via a `<scrip
 
 ## Use
 
-If your `.xlsx` file only has a single "sheet", or if you only care for a single "sheet", or if you don't know or care what a "sheet" is, use `readSheet()` function.
+If your `.xlsx` file only has a single "sheet", or if you only need to read a single "sheet", or if you don't care what a "sheet" is, use `readSheet()` function.
+
+For example, consider the following `.xlsx` file:
 
 | Name       | Date of Birth | Married | Kids |
 | ---------- | ------------- | ------- | ---- |
 | John Smith | 1/1/1995      | TRUE    | 3    |
 | Kate Brown | 3/1/2010      | FALSE   | 0    |
 
+Here's how to read it using `readSheet()` function:
+
 ```js
 import { readSheet } from 'read-excel-file/node'
 
-await readSheet(file)
-
-// Returns
+await readSheet(file) ===
 [
   ['Name', 'Date of Birth', 'Married', 'Kids'],
   ['John Smith', 1995-01-01T00:00:00.000Z, true, 3],
@@ -104,20 +129,18 @@ await readSheet(file)
 ]
 ```
 
-It resolves to an array of rows. Each row is an array of values — `string`, `number`, `boolean` or `Date`.
+The result is an array of rows. Each row is an array of values — `string`, `number`, `boolean` or `Date`.
 
 <!-- It's same as the default exported function shown above with the only difference that it returns just `data` instead of `[{ name: 'Sheet1', data }]`, so it's just a bit simpler to use. It has an optional second argument — `sheet` — which could be a sheet number (starting from `1`) or a sheet name. By default, it reads the first sheet. -->
 
-And it has an optional second argument — `sheet` — which could be a sheet number (starting from `1`) or a sheet name. By default, it reads the first sheet.
+It also has an optional second argument — `sheet` — which could be a sheet number (starting from `1`) or a sheet name. By default, it reads the first sheet.
 
-But if you need to read all "sheets" for some reason, use the default exported function which resolves to an array of "sheets".
+But if you need to read all available "sheets" in a file, use the default exported function:
 
 ```js
 import readExcelFile from 'read-excel-file/node'
 
-await readExcelFile(file)
-
-// Returns
+await readExcelFile(file) ===
 [{
   sheet: 'Sheet1',
   data: [
@@ -131,19 +154,21 @@ await readExcelFile(file)
 }]
 ```
 
-At least one "sheet" always exists. Each "sheet" is an object with properties:
+The result is a non-empty array of "sheets". Each "sheet" is an object with properties:
 * `sheet` — Sheet name.
   * Example: `"Sheet1"`
 * `data` — Sheet data. An array of rows. Each row is an array of values — `string`, `number`, `boolean` or `Date`.
   * Example: `[ ['Name','Age'], ['John Smith',30], ['Kate Brown',15] ]`
 
-## API
+## Import
 
 This package provides a separate `import` path for each different environment, as described below.
 
 ### Browser
 
-It can read a [`File`](https://developer.mozilla.org/en-US/docs/Web/API/File), a [`Blob`](https://developer.mozilla.org/en-US/docs/Web/API/Blob) or an [`ArrayBuffer`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/ArrayBuffer).
+`read-excel-file/browser`
+
+It can read from a [`File`](https://developer.mozilla.org/en-US/docs/Web/API/File), a [`Blob`](https://developer.mozilla.org/en-US/docs/Web/API/Blob) or an [`ArrayBuffer`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/ArrayBuffer).
 
 Example: User chooses a file and the web application reads it.
 
@@ -180,7 +205,7 @@ const data = await readSheet(blob)
 
 ######
 
-All exports of `read-excel-file` already use a [Web Worker](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers) under the hood when reading `.xlsx` file contents. This is in order to avoid freezing the UI when reading large files. So using an additional Web Worker on top of that isn't really necessary. Still, for those who require it, this example shows how a user chooses a file and the web application reads it in a [Web Worker](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers).
+All exports of `read-excel-file` already use a [Web Worker](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers) under the hood when reading `.xlsx` file contents. This is in order to avoid freezing the UI when reading large files. So using an additional Web Worker on top of that isn't really necessary. Still, for those who require it, this example shows how a user chooses a file and the web application reads it in a [Web Worker](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers) using `read-excel-file/web-worker` import path.
 
 ```js
 // Step 1: Initialize Web Worker.
@@ -219,7 +244,9 @@ onmessage = async function(event) {
 
 ### Node.js
 
-It can read a file path, a [`Stream`](https://nodejs.org/api/stream.html), a [`Buffer`](https://nodejs.org/api/buffer.html) or a [`Blob`](https://developer.mozilla.org/docs/Web/API/Blob).
+`read-excel-file/node`
+
+It can read from a file path, a [`Stream`](https://nodejs.org/api/stream.html), a [`Buffer`](https://nodejs.org/api/buffer.html) or a [`Blob`](https://developer.mozilla.org/docs/Web/API/Blob).
 
 Example 1: Read from a file path.
 
@@ -239,6 +266,8 @@ const data = await readSheet(fs.createReadStream('/path/to/file'))
 
 ### Universal
 
+`read-excel-file/universal`
+
 This one works both in a web browser and Node.js. It can only read from a [`Blob`](https://developer.mozilla.org/en-US/docs/Web/API/Blob) or an [`ArrayBuffer`](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/ArrayBuffer), which could be a bit less convenient for general use.
 
 ```js
@@ -295,14 +324,14 @@ Here're the results of reading [sample `.xlsx` files](https://examplefile.com/do
 
 ## Schema
 
-Oftentimes, the task is not just to read the "raw" spreadsheet data but also to convert each row of that data to a JSON object having a certain structure. Because it's such a common task, this package exports a named function `parseData(data, schema)` which does exactly that. It parses sheet data into an array of JSON objects according to a pre-defined `schema` which describes how should a row of data be converted to a JSON object.
+Oftentimes, the task is not just to read the "raw" spreadsheet data but also to convert each row of that data to a JSON object having a certain structure. Because it's such a common task, this package exports a named function `parseSheetData(data, schema)` which does exactly that. It parses sheet data into an array of JSON objects according to a pre-defined `schema` which describes how should a row of data be converted to a JSON object.
 
 ```js
-import { readSheet, parseData } from "read-excel-file/browser"
+import { readSheet, parseSheetData } from "read-excel-file/browser"
 
 const data = await readSheet(file)
 const schema = { ... }
-const { objects, errors } = parseData(data, schema)
+const { objects, errors } = parseSheetData(data, schema)
 if (errors) {
   console.error(errors)
 } else {
@@ -310,7 +339,7 @@ if (errors) {
 }
 ```
 
-The `parseData()` function returns an object — `{ objects, errors }`. Depending on whether there were any errors when parsing the data, either `objects` or `errors` property will be `undefined`.
+The `parseSheetData()` function returns an object — `{ objects, errors }`. Depending on whether there were any errors when parsing the data, either `objects` or `errors` property will be `undefined`.
 
 The sheet data that is being parsed should adhere to a simple structure: the first row should be a header row with just column titles, and each following row should specify the values for those columns.
 
@@ -437,7 +466,7 @@ const schema = {
 const data = await readSheet(file)
 
 // Parse `data` using a `schema`
-const { objects, errors } = parseData(data, schema)
+const { objects, errors } = parseSheetData(data, schema)
 
 // There have been no errors when parsing the sheet data, so `errors` is `undefined`.
 // Should there have been any errors when parsing the sheet data, `errors` would've been
@@ -480,9 +509,9 @@ function PhoneNumber(value) {
 import type {
   Schema,
   CellValue,
-  ParseDataError,
-  ParseDataCustomType,
-  ParseDataCustomTypeErrorMessage
+  ParseSheetDataError,
+  ParseSheetDataCustomType,
+  ParseSheetDataCustomTypeErrorMessage
 } from 'read-excel-file/node'
 
 type ColumnTitle = 'COLUMN TITLE 1' | 'COLUMN TITLE 2'
@@ -496,20 +525,20 @@ function CustomType(value: CellValue): CustomTypeValue {
   return '~' + value + '~'
 }
 
-type CustomTypeErrorMessage<Type extends ParseDataCustomType<unknown>> =
+type CustomTypeErrorMessage<Type extends ParseSheetDataCustomType<unknown>> =
   Type extends typeof CustomType
     ? 'not_a_string'
     : never
 
 // type CustomTypeErrorReason<
-//   Type extends ParseDataCustomType<unknown>,
-//   ErrorMessage extends ParseDataCustomTypeErrorMessage<Type>
+//   Type extends ParseSheetDataCustomType<unknown>,
+//   ErrorMessage extends ParseSheetDataCustomTypeErrorMessage<Type>
 // > =
 //   Type extends typeof CustomType
 //     ? (ErrorMessage extends 'not_a_string' ? undefined : never)
 //     : never
 
-type PossibleError = ParseDataError<
+type PossibleError = ParseSheetDataError<
   ColumnTitle,
   typeof CustomType,
   CustomTypeErrorMessage<typeof CustomType>
@@ -533,7 +562,7 @@ const schema: Schema<Object, ColumnTitle> = {
   }
 }
 
-const { objects, errors } = parseData<Object, ColumnTitle, PossibleError>([
+const { objects, errors } = parseSheetData<Object, ColumnTitle, PossibleError>([
   ['COLUMN TITLE 1', 'COLUMN TITLE 2'],
   ['Value 1', 'Value 2']
 ], schema)

package/browser/index.cjs

@@ -3,8 +3,8 @@ exports['default'] = require('../commonjs/export/readXlsxFileBrowser.js').defaul
 
 exports.readSheet = require('../commonjs/export/readSheetBrowser.js').default
 
-// `parseData()`
-exports.parseData = require('../commonjs/parseData/parseData.js').default
-exports.Integer = require('../commonjs/parseData/types/additional/Integer.js').default
-exports.Email = require('../commonjs/parseData/types/additional/Email.js').default
-exports.URL = require('../commonjs/parseData/types/additional/URL.js').default
+// `parseSheetData()`
+exports.parseSheetData = require('../commonjs/parseSheetData/parseSheetData.js').default
+exports.Integer = require('../commonjs/parseSheetData/types/additional/Integer.js').default
+exports.Email = require('../commonjs/parseSheetData/types/additional/Email.js').default
+exports.URL = require('../commonjs/parseSheetData/types/additional/URL.js').default

package/browser/index.d.ts

@@ -10,17 +10,17 @@ import {
 } from '../types/types.d.js';
 
 import {
-	ParseDataOptions,
-	ParseDataResult
-} from '../types/parseData/parseData.d.js';
+	ParseSheetDataOptions,
+	ParseSheetDataResult
+} from '../types/parseSheetData/parseSheetData.d.js';
 
 import {
 	Schema
-} from '../types/parseData/parseDataSchema.d.js';
+} from '../types/parseSheetData/parseSheetDataSchema.d.js';
 
 import {
-	ParseDataError
-} from '../types/parseData/parseDataError.d.js';
+	ParseSheetDataError
+} from '../types/parseSheetData/parseSheetDataError.d.js';
 
 export {
 	CellValue,
@@ -30,7 +30,7 @@ export {
 } from '../types/types.d.js';
 
 export {
-	ParseDataCustomType,
+	ParseSheetDataCustomType,
 	// Base `type`s when parsing data.
 	StringType as String,
 	DateType as Date,
@@ -40,22 +40,22 @@ export {
 	Integer,
 	Email,
 	URL
-} from '../types/parseData/parseDataValueType.d.js';
+} from '../types/parseSheetData/parseSheetDataValueType.d.js';
 
 export {
-	ParseDataCustomTypeErrorMessage,
-	ParseDataCustomTypeErrorReason,
-	ParseDataError,
-	ParseDataValueRequiredError
-} from '../types/parseData/parseDataError.d.js';
+	ParseSheetDataCustomTypeErrorMessage,
+	ParseSheetDataCustomTypeErrorReason,
+	ParseSheetDataError,
+	ParseSheetDataValueRequiredError
+} from '../types/parseSheetData/parseSheetDataError.d.js';
 
 export {
-	ParseDataResult
-} from '../types/parseData/parseData.d.js';
+	ParseSheetDataResult
+} from '../types/parseSheetData/parseSheetData.d.js';
 
 export {
 	Schema
-} from '../types/parseData/parseDataSchema.d.js';
+} from '../types/parseSheetData/parseSheetDataSchema.d.js';
 
 export default function readXlsxFile<ParsedNumber = number>(
 	input: Input,
@@ -73,12 +73,12 @@ export function readSheet<ParsedNumber = number>(
 	options?: ReadOptions<ParsedNumber>
 ): Promise<SheetData<ParsedNumber>>;
 
-export function parseData<
+export function parseSheetData<
 	Object extends object,
 	ColumnTitle extends string,
-	Error extends ParseDataError
+	Error extends ParseSheetDataError
 >(
 	data: SheetData,
 	schema: Schema<Object, ColumnTitle>,
-	options?: ParseDataOptions
-): ParseDataResult<Object, Error>;
+	options?: ParseSheetDataOptions
+): ParseSheetDataResult<Object, Error>;

package/browser/index.js

@@ -1,8 +1,8 @@
 export { default as default } from '../modules/export/readXlsxFileBrowser.js'
 export { default as readSheet } from '../modules/export/readSheetBrowser.js'
 
-// `parseData()`
-export { default as parseData } from '../modules/parseData/parseData.js'
-export { default as Integer } from '../modules/parseData/types/additional/Integer.js'
-export { default as Email } from '../modules/parseData/types/additional/Email.js'
-export { default as URL } from '../modules/parseData/types/additional/URL.js'
+// `parseSheetData()`
+export { default as parseSheetData } from '../modules/parseSheetData/parseSheetData.js'
+export { default as Integer } from '../modules/parseSheetData/types/additional/Integer.js'
+export { default as Email } from '../modules/parseSheetData/types/additional/Email.js'
+export { default as URL } from '../modules/parseSheetData/types/additional/URL.js'

package/commonjs/parseSheetData/InvalidError.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"InvalidError.js","names":["InvalidError","exports","_Error","_inherits","_super","_createSuper","reason","_this","_classCallCheck","call","_createClass","_wrapNativeSuper","Error"],"sources":["../../source/parseSheetData/InvalidError.js"],"sourcesContent":["export default class InvalidError extends Error {\r\n  constructor(reason) {\r\n    super('invalid')\r\n    this.reason = reason\r\n  }\r\n}"],"mappings":";;;;;;;;;;;;;;;;;;;;;;IAAqBA,YAAY,GAAAC,OAAA,qCAAAC,MAAA;EAAAC,SAAA,CAAAH,YAAA,EAAAE,MAAA;EAAA,IAAAE,MAAA,GAAAC,YAAA,CAAAL,YAAA;EAC/B,SAAAA,aAAYM,MAAM,EAAE;IAAA,IAAAC,KAAA;IAAAC,eAAA,OAAAR,YAAA;IAClBO,KAAA,GAAAH,MAAA,CAAAK,IAAA,OAAM,SAAS;IACfF,KAAA,CAAKD,MAAM,GAAGA,MAAM;IAAA,OAAAC,KAAA;EACtB;EAAC,OAAAG,YAAA,CAAAV,YAAA;AAAA,gBAAAW,gBAAA,CAJuCC,KAAK"}

package/commonjs/{parseData/parseData.js → parseSheetData/parseSheetData.js}

@@ -3,10 +3,10 @@
 Object.defineProperty(exports, "__esModule", {
   value: true
 });
-exports["default"] = parseData;
+exports["default"] = parseSheetData;
 exports.getNextSubstring = getNextSubstring;
-exports.parseDataWithPerRowErrors = parseDataWithPerRowErrors;
 exports.parseSeparatedSubstrings = parseSeparatedSubstrings;
+exports.parseSheetDataWithPerRowErrors = parseSheetDataWithPerRowErrors;
 exports.parseValue = parseValue;
 var _Number = _interopRequireDefault(require("./types/Number.js"));
 var _String = _interopRequireDefault(require("./types/String.js"));
@@ -56,10 +56,10 @@ function _arrayLikeToArray(arr, len) { if (len == null || len > arr.length) len
  * @param {string} [options.separatorCharacter] — When specified, string values will be split by this separator to get the array.
  * @return {object} — An object of shape `{ objects, errors }`. Either `objects` or `errors` is going to be `undefined`.
  */
-function parseData(data, schema, optionsCustom) {
+function parseSheetData(data, schema, optionsCustom) {
   var objects = [];
   var errors = [];
-  var parsedRows = parseDataWithPerRowErrors(data, schema, optionsCustom);
+  var parsedRows = parseSheetDataWithPerRowErrors(data, schema, optionsCustom);
   var parsedRowIndex = 0;
   for (var _iterator = _createForOfIteratorHelperLoose(parsedRows), _step; !(_step = _iterator()).done;) {
     var _step$value = _step.value,
@@ -86,7 +86,7 @@ function parseData(data, schema, optionsCustom) {
 }
 
 // This one is only used in tests.
-function parseDataWithPerRowErrors(data, schema, optionsCustom) {
+function parseSheetDataWithPerRowErrors(data, schema, optionsCustom) {
   validateSchema(schema);
   var options = applyDefaultOptions(optionsCustom);
   var _data = _toArray(data),
@@ -728,4 +728,4 @@ var objectConstructor = {}.constructor;
 function isObject(object) {
   return object !== undefined && object !== null && object.constructor === objectConstructor;
 }
-//# sourceMappingURL=parseData.js.map
+//# sourceMappingURL=parseSheetData.js.map