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

Return null rather than {} when mimos.type() finds no match #38

Closed
devinivy opened this issue May 5, 2021 · 2 comments
Closed

Return null rather than {} when mimos.type() finds no match #38

devinivy opened this issue May 5, 2021 · 2 comments
Labels
breaking changes Change that can breaking existing code feature New functionality or improvement

Comments

@devinivy
Copy link
Member

devinivy commented May 5, 2021

Support plan

  • is this issue currently blocking your project? (yes/no): no
  • is this issue affecting a production system? (yes/no): no

Context

  • node version: v12+
  • module version: v5/v6
  • environment (e.g. node, browser, native): node
  • used with (e.g. hapi application, another framework, standalone, ...): hapi
  • any other relevant information: This would be a breaking change that would propagate to hapi's API 🚨 , since hapi exposes an instance of mimos through server.mime.

What problem are you trying to solve?

The interface of the Mimos instance can be awkward to work with (particularly with typescript) because mimos.type() returns an empty object {} when there is no mime type match, and an object with some properties when there is a match.

Do you have a new or modified API suggestion to solve the problem?

The proposal from #37 is for mimos.path() to return null when there is no mime type match.

@devinivy devinivy added breaking changes Change that can breaking existing code feature New functionality or improvement labels May 5, 2021
@kanongil
Copy link
Contributor

FYI, I'm not sure the enhanced ergonomics is worth the potential issues this can create with old code, as per #37 (comment).

@devinivy
Copy link
Member Author

devinivy commented May 9, 2022

I'm comfortable with that 👍

@devinivy devinivy closed this as completed May 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking changes Change that can breaking existing code feature New functionality or improvement
Projects
None yet
Development

No branches or pull requests

2 participants