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

import {getType} from 'mime' no longer works in mime@4 #295

Closed
broofa opened this issue Dec 2, 2023 · 1 comment
Closed

import {getType} from 'mime' no longer works in mime@4 #295

broofa opened this issue Dec 2, 2023 · 1 comment

Comments

@broofa
Copy link
Owner

broofa commented Dec 2, 2023

As noted by @MartinX3, directly importing properties of the mime object - e.g. import { getType } from 'mime'; - no longer works in mime@4.

First, it's worth noting that this sort of import was technically never a documented part of the API. The README has always recommended importing and accessing the API through the mime object. That said, I'm not surprised that some devs prefer this style of import. And judging by the code, I apparently went out of my way to support it at some point. So... fine, "we'll allow it." 😄

That said, I consider the new behavior to be "working as intended". It's a natural consequence of a couple important architectural changes in v4. Specifically:

  1. Object-based API. Having the mime API rooted in instances of a Mime class allows for a clean separation between immutable, default objects and mutable, custom objects. Thus, it makes sense to export the mime object as a whole. This is how the code was structured previously, but the new version really leans into this decision in ways it didn't used to.
  2. Switching to ESM-only. ESM doesn't support exporting all properties of an object by design. Doing so gets awkward and is arguably a bit of a code-smell.

While maintaining backward compatibility is doable, it would require a couple of code patterns that I don't particularly care for. And since this is a major-version release I think it's appropriate to drop support at this time.

For those affected by this, my apologies. There's a couple options...

Option 1: Patch affected code (recommended)

For most users, just patch up your existing code.

// Change this:
import {getType} from 'mime';
// ... to this:
import mime from 'mime';

// ... and change calls like this:
const type = getType(someType);
// ... to this:
const type = mime.getType(someType);

Option 2: Create local var(s) bound to the mime instance

If for some reason you have bunch of call sites that you'd rather not deal with updating (why?!?), you can do this.

// Change this:
import {getType} from 'mime';
// ... to this:
import mime from 'mime';
const getType = mime.getType.bind(mime);

Option 3: Use dynamic import()

If you happen to be dynamically require()'ing or import()'ing mime already, you can just destructure the defualt object. I wouldn't recommend this otherwise, however.

// Change this:
import { getType } from 'mime';
// ... to this:
const { getType } = (await import('mime')).default

Option 4: Create a helper module that binds and exports the desired properties

Lastly, if you have a bunch of code affected by this and really want to miminize your code churn I suppose you can do something like this. ('Would love to hear the use case for this, if anyone actually has one.)

// --- "mime-helper.js" ---
import mime from 'mime';
const getType = mime.getType.bind(mime);
export { getType, getExtension, getAllExtensions };

// Then, elsewhere, change this:
import { getType } from 'mime';
// ... to this:
import { getType } from './mime-helper.js';
MartinX3 added a commit to Rad-Touristik-Club-Koln-e-V-1972/Rad-Touristik-Club-Koln-e-V-1972.github.io that referenced this issue Dec 2, 2023
See broofa/mime#295

Signed-off-by: Martin Dünkelmann <nc-duenkekl3@netcologne.de>
MartinX3 added a commit to Rad-Touristik-Club-Koln-e-V-1972/Rad-Touristik-Club-Koln-e-V-1972.github.io that referenced this issue Dec 2, 2023
code works as intended

See broofa/mime#295

Signed-off-by: Martin Dünkelmann <nc-duenkekl3@netcologne.de>
@broofa
Copy link
Owner Author

broofa commented Dec 2, 2023

@MartinX3, 'looks like you've fixed the problem. Thanks for the report.

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

1 participant