Skip to content

Add a way to acknowledge or suppress warnings for upcoming default option changes #10584

Description

@MrEkinox

Parse Server 9.10.0 emits multiple deprecation warnings every time a server instance starts for options whose default values will change in a future release.

I understand that this behavior is intentional: when an option is omitted, the application implicitly relies on its current default value.

However, there is currently no global way to acknowledge these upcoming changes or suppress the related warnings.

This is particularly problematic in Jest tests, where Parse Server instances may be started repeatedly. Every server startup emits the complete list of warnings, causing the test console to be heavily spammed and making actual test failures and relevant logs harder to identify.

Steps to reproduce

Start a Parse Server instance without explicitly defining every option whose default value will change:

import { ParseServer } from 'parse-server';

const server = new ParseServer({
  databaseURI: process.env.DATABASE_URI,
  appId: 'app',
  masterKey: 'master-key',
  serverURL: 'http://localhost:1337/parse',
  logLevel: 'error',
});

await server.start();

When this setup is used in Jest and the server is started for multiple test suites or test environments, the warnings are printed again on every startup.

Actual behavior

Parse Server emits the following warnings:

warn: DeprecationWarning: The Parse Server option 'pages.encodePageParamHeaders' default will change to 'true' in a future version. Set 'pages.encodePageParamHeaders' to 'true' to URI-encode non-ASCII characters in page parameter headers.

warn: DeprecationWarning: The Parse Server option 'readOnlyMasterKeyIps' default will change to '["127.0.0.1", "::1"]' in a future version. Set 'readOnlyMasterKeyIps' to the IP addresses that should be allowed to use the read-only master key, or to '["127.0.0.1", "::1"]' to restrict access to localhost.

warn: DeprecationWarning: The Parse Server option 'requestComplexity.includeDepth' default will change to '10' in a future version. Set 'requestComplexity.includeDepth' to a positive integer appropriate for your app to limit include pointer chain depth, or to '-1' to disable.

warn: DeprecationWarning: The Parse Server option 'requestComplexity.includeCount' default will change to '100' in a future version. Set 'requestComplexity.includeCount' to a positive integer appropriate for your app to limit the number of include paths per query, or to '-1' to disable.

warn: DeprecationWarning: The Parse Server option 'requestComplexity.subqueryDepth' default will change to '10' in a future version. Set 'requestComplexity.subqueryDepth' to a positive integer appropriate for your app to limit subquery nesting depth, or to '-1' to disable.

warn: DeprecationWarning: The Parse Server option 'requestComplexity.queryDepth' default will change to '10' in a future version. Set 'requestComplexity.queryDepth' to a positive integer appropriate for your app to limit query condition nesting depth, or to '-1' to disable.

warn: DeprecationWarning: The Parse Server option 'requestComplexity.graphQLDepth' default will change to '20' in a future version. Set 'requestComplexity.graphQLDepth' to a positive integer appropriate for your app to limit GraphQL field selection depth, or to '-1' to disable.

warn: DeprecationWarning: The Parse Server option 'requestComplexity.graphQLFields' default will change to '200' in a future version. Set 'requestComplexity.graphQLFields' to a positive integer appropriate for your app to limit the number of GraphQL field selections, or to '-1' to disable.

warn: DeprecationWarning: The Parse Server option 'requestComplexity.batchRequestLimit' default will change to '100' in a future version. Set 'requestComplexity.batchRequestLimit' to a positive integer appropriate for your app to limit the number of sub-requests per batch request, or to '-1' to disable.

warn: DeprecationWarning: The Parse Server option 'protectedFieldsOwnerExempt' default will change to 'false' in a future version. Set 'protectedFieldsOwnerExempt' to 'false' to apply protectedFields consistently to the user's own `_User` object, or to 'true' to keep the current behavior.

warn: DeprecationWarning: The Parse Server option 'protectedFieldsTriggerExempt' default will change to 'true' in a future version. Set 'protectedFieldsTriggerExempt' to 'true' to make Cloud Code triggers receive the full object including protected fields, or to 'false' to keep the current behavior.

warn: DeprecationWarning: The Parse Server option 'protectedFieldsSaveResponseExempt' default will change to 'false' in a future version. Set 'protectedFieldsSaveResponseExempt' to 'false' to strip protected fields from write operation responses, or to 'true' to keep the current behavior.

warn: DeprecationWarning: The Parse Server option 'installation.duplicateDeviceTokenActionEnforceAuth' default will change to 'true' in a future version. Set it to 'true' to enforce the caller's authentication context or to 'false' to keep the current behavior.

warn: DeprecationWarning: The Parse Server option 'allowAggregationForReadOnlyMasterKey' default will change to 'false' in a future version. Set it to 'false' to prevent the read-only master key from running aggregation pipelines, or to 'true' to keep the current behavior.

The warnings are still emitted when logLevel is set to "error".

In a test environment, this entire output is repeated each time a Parse Server instance starts.

Current implementation

The warnings are emitted by Deprecator.scanParseServerOptions when an option with an upcoming default change is not explicitly defined:

static scanParseServerOptions(options) {
  // Scan for deprecations
  for (const deprecation of Deprecator._getDeprecations()) {
    // Get deprecation properties
    const solution = deprecation.solution;
    const optionKey = deprecation.optionKey;
    const changeNewDefault = deprecation.changeNewDefault;
    const changeNewKey = deprecation.changeNewKey;

    // If default will change, only throw a warning if option is not set
    if (
      changeNewDefault != null &&
      Utils.getNestedProperty(options, optionKey) == null
    ) {
      Deprecator._logOption({
        optionKey,
        changeNewDefault,
        solution,
      });
    }

    // If key will be removed or renamed, only throw a warning if option is set;
    // skip if option is set to the resolved value that suppresses the deprecation
    const resolvedValue = deprecation.resolvedValue;
    const optionValue = Utils.getNestedProperty(options, optionKey);

    if (
      changeNewKey != null &&
      optionValue != null &&
      optionValue !== resolvedValue
    ) {
      Deprecator._logOption({
        optionKey,
        changeNewKey,
        solution,
      });
    }
  }
}

The current behavior makes sense for notifying users who may unknowingly rely on existing defaults. However, it does not provide a convenient way to indicate that these changes have already been reviewed and accepted.

Expected behavior

Parse Server should provide a supported way to acknowledge or suppress warnings related to upcoming default changes.

This would be especially useful in test environments, where the same warnings do not need to be printed every time a temporary Parse Server instance starts.

For example:

const server = new ParseServer({
  // ...
  acknowledgeFutureDefaults: true,
});

Another possible solution could be:

const server = new ParseServer({
  // ...
  deprecationWarnings: false,
});

Other possible approaches include:

  • Making deprecation warnings respect the existing logLevel.
  • Providing a dedicated log level or logger for deprecation warnings.
  • Emitting each warning only once per process.
  • Emitting one consolidated warning instead of one warning per option.
  • Automatically suppressing repeated warnings after the first server startup.
  • Providing a helper that applies or acknowledges all future defaults.

Motivation

The warnings are useful during development and migration, but repeating the complete list every time a server starts is unnecessarily noisy.

This is particularly disruptive with Jest:

  • Test suites may create multiple Parse Server instances.
  • The complete warning list is printed for every instance.
  • Relevant application warnings and test failures become harder to find.
  • logLevel: "error" does not prevent the warnings from being printed.
  • Explicitly copying every future default into the test configuration adds unnecessary boilerplate.

Emitting each warning only once per process would already significantly improve the Jest experience while preserving the migration notice.

Environment

  • Parse Server: 9.10.0
  • Node.js: 24.18.0
  • Database: MongoDB
  • Operating system: macOS
  • Test runner: Jest

Metadata

Metadata

Assignees

No one assigned

    Labels

    type:featureNew feature or improvement of existing feature

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions