Type error '"@hapi/hapi"' has no exported member named 'Util'. Did you mean 'Utils'?

eriktoyra commented 2 months ago

Runtime

Node.js

Runtime version

v20.10.0

Module version

21.3.10

Last module version without issue

21.0.0

Used with

@apollo/server, @as-integrations/hapi

Any other relevant information

@hapi/hapi 21.0.0 with @types/hapi_hapi 20.0.13 installed works. But since @types/hapi_hapi should not be used with @hapi/hapi 21.0+ this is not an option.

What are you trying to achieve or the steps to reproduce?

When updating Apollo Server from v3 to v4 I stumbled on a breaking change in the type definitions provided in a change targeting Hapi@21.1.0.

It seems the namespace Util, previously provided by DefinatelyTyped in@types/hapi_hapi, has been renamed from Util to Utils by mistake. #4398 moved the type definitions as-is from @types/hapi_hapi into Hapi. But in the subsequent #4399 when the type definitions where split out to multiple files, the namespace was renamed from Util to Utils.

Compare this line of code with the the resulting change in #4399. This seems like a typo mistake. But it infers a breaking change in other packages referencing Util.

What was the result you got?

@as-integrations references the Util type from @hapi/hapi, as this is the expected name up until the change in #4399. This leads to a breaking change towards @as-integrations and other packages importing Util from @hapi/hapi.

import type {
  Lifecycle,
  ReqRef,
  Request,
  ResponseToolkit,
  RouteOptions,
  Server,
  Util,
} from '@hapi/hapi';

This leads to the type error:

'"@hapi/hapi"' has no exported member named 'Util'. Did you mean 'Utils'? ts(2724)

What result did you expect?

@hapi/hapi should provide Util as namespace and not Utils for backward compatibility.

eriktoyra commented 2 months ago

~Happy~ Hapi to raise a PR to fix this by the way. Just let me know.

kanongil commented 2 months ago

Thanks for the very detailed report.

Hapi doesn't usually provide this kind of back-compat measures. I think this would be best fixed in @as-integrations, by not relying on the Util.Dictionary type. This should be able to be easily replaced with the built-in Record type or a typeof Request['headers'].

In the meantime, I think you should be able to get your project to compile using the TS skipLibCheck option.

eriktoyra commented 2 months ago

Thank's for the info!

I would assume the comment // Kept for backwards compatibility only (remove in next major) on https://github.com/hapijs/hapi/blob/master/lib/types/index.d.ts#L15 indicates that there was an intention to be backwards compatible and later remove this namespace in a major. But unfortunately it was renamed in a minor in the process, causing a breaking change towards other projects (our own included).

I totally agree that this could better be resolved in consuming projects to not rely on Util.Dictionary. I'll raise an issue there and we'll see what it gives. Until then I'm going to downgrade @hapi/hapi to make this work as skipLibCheck is not an option in our project.

hapijs / hapi