Node < 20 compatibility issue: ReferenceError: File is not defined in v10.0.0

[manisatwick]

Node.js compatibility issue: ReferenceError: File is not defined in v10.0.0

Bug Description
The json-schema-library v10.0.0 throws a ReferenceError: File is not defined when running in Node.js environments. The library appears to be trying to access browser-specific APIs (File, FileList, FileReader) that are not available in Node.js.

Environment

• json-schema-library version: 10.0.0
• Node.js version: v18.19.0
• npm version: 10.2.3
• Operating System: Windows/Linux/macOS
• Module type: ES modules ("type": "module" in package.json)

Steps to Reproduce

1. Install json-schema-library v10.0.0 in a Node.js project with ES modules
2. Try to use compileSchema and call getData() on the compiled schema

Minimal reproduction case:

import pkg from 'json-schema-library';
const { compileSchema } = pkg;

const simpleSchema = {
  type: 'object',
  properties: {
    name: { type: 'string' },
    age: { type: 'number' }
  }
};

const compiledSchema = compileSchema(simpleSchema);
const data = compiledSchema.getData({}); // Throws: ReferenceError: File is not defined

Expected Behavior

The library should work seamlessly in Node.js environments without requiring browser-specific polyfills.

Actual Behavior

ReferenceError: File is not defined
    at Object.getData (node_modules/json-schema-library/dist/jsonSchemaLibrary.js:1:111100)
    at Object.getData (node_modules/json-schema-library/dist/jsonSchemaLibrary.js:1:38206)

Current Workaround

Adding Node.js polyfills for browser APIs:

if (typeof global !== 'undefined') {
  if (!global.File) {
    (global as any).File = class File {
      constructor(public name: string) {}
    };
  }
  
  if (!global.FileList) {
    (global as any).FileList = class FileList {
      length = 0;
      item() { return null; }
    };
  }
  
  if (!global.FileReader) {
    (global as any).FileReader = class FileReader {
      readAsText() {}
      addEventListener() {}
    };
  }
}

Analysis

The issue appears to be that the library is designed for browser environments and tries to access File, FileList, and FileReader objects that don't exist in Node.js. For a schema validation/compilation library, these browser-specific APIs shouldn't be necessary for core functionality.

Expected Fix

The library should either:

1. Detect the environment and avoid using browser-specific APIs in Node.js
2. Provide built-in polyfills for Node.js environments
3. Make the browser-specific functionality optional/conditional

Additional Context

This issue prevents the library from being used in server-side applications, CLI tools, and other Node.js environments without manual polyfills. Since schema validation and data generation are common server-side tasks, Node.js compatibility should be a priority.

Package.json Configuration

{
  "type": "module",
  "dependencies": {
    "json-schema-library": "^10.0.0"
  }
}

Impact

• Breaks Node.js compatibility for a library that should work universally
• Requires manual workarounds for server-side usage
• Affects CLI tools, build scripts, and backend applications using the library

[sagold]

Hi manisatwick,

thank you for your thorough issue description! I agree, a File-check should be optional based on environment as the library is build to work on browser and node environments.

I will add a fix soon and keep you posted.

[sagold]

Hi Mani,

a fix for this issue has been published with json-schema-library@10.1.1.

I was wondering why this was not caught in the node test-runs: File is supported by node-versions >= 20 https://nodejs.org/api/buffer.html#class-file, but now we are backwards compatible.

The fix has been tested with node 18.

Thank you so much for reporting the issue!
Sascha

[sagold]

FYI

getData() will return an empty object in your example. Per JSON Schema, given properties are optional. If you want create data for those properties you have two options:

1 set properties as required in JSON Schema

const simpleSchema = {
  type: 'object',
+  required: ["name", "age"],
  properties: {
    name: { type: 'string' },
    age: { type: 'number' }
  }
};

2 Or set getData() to add all optional properties automatically:

const compiledSchema = compileSchema(simpleSchema, { getDataDefaultOptions: { addOptionalProps: true } });

[manisatwick]

Hi Sascha,

Thanks so much for this awesome project—really appreciate the work you've put into it!

I had a quick question: is there a way to override the default value for a specific data type? For example, I'd like to return a specific string like "N/A" or null as the default for a property of type string when it's optional in the JSON Schema. Is that possible within the current setup?

Thanks again!

Best,
Mani Satwick

[sagold]

Thank you for your feedback!

To return a default-value use the JSON Schema default property. getData will use this value if it is missing and not optional.

If an optional property should be set, it is not optional. Some way to still add to your property would be to set a partial object as default value on the object.

For a better understanding you can reference the test here: https://github.com/sagold/json-schema-library/blob/main/src/methods/getData.test.ts

[manisatwick]

I have a schema where the input type is a string with a defined enum and a default value. However, instead of returning the specified default, the first value in the enum is returned.
{
type: 'string',
minLength: 1,
enum: ['value1', 'value2', 'value3', 'value4'],
default: ''
}

[sagold]

Hi,

the default value for enums is overriden by the first entry as "" is an invalid value for this schema. The purpose of getData is to generate valid data against the schema. Adding an enum-option: "" would solve this.

On the other hand, in most situations it is allowed to set invalid data per default. I will investigate what a consistent solution would be.

What is your expectation here?

[manisatwick]

Hi Sascha,

In the above scenario, I was expecting the default value defined in the schema to be returned, provided it's valid. I understand that flags like extendDefaults and removeInvalidData may influence how defaults and invalid values are handled.

However, even with these flags enabled, the default value is not being returned—instead, the first value from the enum array is used. Could we consider honoring the default value when it's present in the enum?

Additionally, if removeInvalidData is set to true and the default is not part of the enum, then falling back to the first value from the enum seems reasonable.

Thanks,
Mani

[sagold]

Hi Mani,

I agree, the behaviour should be consistent across all schema-types. A fix has been published with v10.1.2 that solves this issue.

Let me know if there are any other issues.

Cheers,
Sascha

[manisatwick]

Hi Sascha,

I’m trying to generate data from a schema such that the resulting object includes only the properties with defined default value properties without defaults should be omitted entirely. I tried setting extendDefaults to false, but it doesn’t seem to be working as expected.

Is there a recommended way to achieve this using the library?

Thanks,
Mani

[sagold]

Hi Mani,

can you post an example with the expected outcome?