-
-
Notifications
You must be signed in to change notification settings - Fork 319
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
Comments
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>
@MartinX3, 'looks like you've fixed the problem. Thanks for the report. |
broofa
added a commit
that referenced
this issue
Dec 2, 2023
cpiber
added a commit
to cpiber/epub-gen-memory
that referenced
this issue
Jul 29, 2024
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
mime
API rooted in instances of aMime
class allows for a clean separation between immutable, default objects and mutable, custom objects. Thus, it makes sense to export themime
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.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.
Option 2: Create local var(s) bound to the
mime
instanceIf for some reason you have bunch of call sites that you'd rather not deal with updating (why?!?), you can do this.
Option 3: Use dynamic
import()
If you happen to be dynamically require()'ing or import()'ing
mime
already, you can just destructure thedefualt
object. I wouldn't recommend this otherwise, however.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.)
The text was updated successfully, but these errors were encountered: