Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make the name type definition explicit (and not just string) #50

Open
codenomnom opened this issue Oct 1, 2024 · 9 comments
Open

Make the name type definition explicit (and not just string) #50

codenomnom opened this issue Oct 1, 2024 · 9 comments

Comments

@codenomnom
Copy link

Summary

As of now, the definition of each status name looks like this:

readonly '100_NAME': string;

Can it be explicit, like:

readonly '100_NAME': 'CONTINUE';

Motivation

The reason for that request is that when we use the name for generic mapping, TS can't properly infer it:

const name = status[`${status.TOO_MANY_REQUESTS}_NAME`];
// its value is indeed "TOO_MANY_REQUESTS"
// but the type is simply "string" (any string)
// which is technically true, and yet cumbersome

// because of that, creating a map doesn't work as best as it could:
const map = {
  [`${status.TOO_MANY_REQUESTS}_NAME`]: 'custom message or something',
}

// IDE cannot figure out that map should contain "TOO_MANY_REQUESTS" key

Alternative

Duplicate names as keys, but that doesn't feel right.

@wdavidw
Copy link
Member

wdavidw commented Oct 1, 2024

I am currently in the process of migrating a few of my package into TS, I could certainly have http-status included in the list and will look in the coming days. I think your suggestion makes sense.

@wdavidw
Copy link
Member

wdavidw commented Oct 17, 2024

I just release version 1.8 which is a typescript rewrite. Please let me know if it corresponds to your expectations.

@wdavidw
Copy link
Member

wdavidw commented Oct 21, 2024

Two new versions are published:

  • version 1.8.1 fixes 1.8.0 and is a copy of the previous version 1.7.4
  • version 2.0.0 is the new version with the convertions to ESM and TypeScript

@wdavidw
Copy link
Member

wdavidw commented Oct 23, 2024

@codenomnom could you take the time to validate version 2 and close the issue if it works accordingly to your expectations. Thank you.

@codenomnom
Copy link
Author

Hey there, sorry for the delay, got sick 🤧 Will ping you shortly, thanks!

@codenomnom
Copy link
Author

@wdavidw thank you for taking time to ping me with the update. I'm not in my brightest shape, but I'm currently missing on how to deal with this use case of mine:

// some error handling catch function
return {
  success: false,
  code: err.statusCode,
  text: HTTPStatuses[err.statusCode],
}

It's like a generic map between some error I received (regardless from where), and I want to translate 401 to Unauthorized, UNAUTHORIZED or Similar to 403 Forbidden, but...

Unfortunately I get this TS error:

Element implicitly has an 'any' type because expression of type 'number' can't be used to index type '{ readonly classes: { readonly "1xx": "Informational"; readonly "1xx_NAME" (...)

Regardless of usage, I get similar errors:

HTTPStatuses[`${err.status}_MESSAGE`]

Element implicitly has an 'any' type because expression of type '${number}_MESSAGE' can't be used to index type '{ readonly classes: { readonly "1xx": "Informational"; (...)

Sorry for not being the brightest I could 😅

@realtebo
Copy link

realtebo commented Oct 27, 2024

I tried to import using

import status from "http-status";

And my linter told me

Cannot find module 'http-status' or its corresponding type declarations.
  There are types at '......../oidc/node_modules/http-status/dist/index.d.ts', 
  but this result could not be resolved under your current 'moduleResolution' 
  setting. Consider updating to 'node16', 'nodenext', or 'bundler'.ts(2307)

I'm using v2.0.0

This is my config

{
    "compilerOptions": {
      "target": "es2020",
      "strict": true,
      "preserveConstEnums": true,
      "noEmit": true,
      "sourceMap": false,
      "module":"es2015",
      "moduleResolution":"node",
      "esModuleInterop": true, 
      "skipLibCheck": true,
      "forceConsistentCasingInFileNames": true,  
    },
    "exclude": ["node_modules", "**/*.test.ts"]
  }

@wdavidw
Copy link
Member

wdavidw commented Oct 28, 2024

@codenomnom, I hope you will get better. I tried that code and it seems to work fine:

import status from "http-status";

const getError = function (statusCode: number) {
  return {
    success: false,
    code: statusCode,
    text: status[statusCode],
  };
};

console.log(getError(400));
node --import tsx samples/issue.50.ts
{
  success: false,
  code: 400,
  text: 'Bad Request',
  message: 'The server cannot or will not process the request due to an apparent client error.'
}

@wdavidw
Copy link
Member

wdavidw commented Oct 28, 2024

@realtebo I you can make the change, try updating your "module" definition to "ESNext" or "NodeNext". Not a specialist in that field but it could help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants