chore: v14.0.0 release

[kamilmysliwiec]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe:

What is the current behavior?

Issue Number: N/A

What is the new behavior?

Does this PR introduce a breaking change?

• Yes
• No

Other information

[kamilmysliwiec]

 - @nestjs/apollo: 13.4.0 => 14.0.0-next.0
 - @nestjs/graphql: 13.4.0 => 14.0.0-next.0
 - @nestjs/mercurius: 13.4.0 => 14.0.0-next.0

have just been published under the next tag

[Angel-Mario]

I noticed there's still a CommonJS import in graphql-types.loader.ts:

const normalize = require('normalize-path');

Would it make sense to replace it with:

import normalize from 'normalize-path';

This is a non-functional change, but it improves compatibility with ESM-first projects and aligns with the upcoming NestJS v12 ESM support. Since normalize-path is a CommonJS package exporting a single function, the default import remains fully compatible with both ESM and CommonJS consumers.

[Angel-Mario]

While testing with an ESM project ("type": "module"), I noticed that this loader still relies on require():

const { expressMiddleware } = await loadPackage(
  '@as-integrations/express5',
  'GraphQLModule',
  () => require('@as-integrations/express5'),
);

Since require isn't available in ESM modules, this throws at runtime.

Changing the loader callback to use a dynamic import instead resolves the issue:

const { expressMiddleware } = await loadPackage(
  '@as-integrations/express5',
  'GraphQLModule',
  () => import('@as-integrations/express5'),
);

I tested this locally and it fixes the ESM runtime error while preserving the existing lazy-loading behavior. It also helps improve compatibility with the upcoming NestJS v12 ESM support.