Use plugin architecture instead of custom builds (RFC)

[krmax44]

I'd like to propose using ESM imports and a plugin system as an addition (or replacement) for custom builds. To me, this has the following advantages:

• Much more flexible, no re-builds required when needs change
• No build tools required for end-users, resulting in much faster installs
• Everyone uses the same release code, making it reproducable and easier to debug
• More in-line of how other tools work, treeshaking is expected to work without manual tinkering

The API could look something like this:

import ExifReader, { png, jpeg, DateTime, GPSCoordinates } from 'exifreader';

const exifReader = new ExifReader().use(png, jpeg, DateTime, GPSCoordinates);
const tags = await exifReader.load(file);

Since we only import some modules, the build processor can exclude the unused ones.

[mattiasw]

This looks interesting. I like the idea of being able to use tree shaking, and getting rid of the postinstall script. It would also make the code a lot simpler.

I can see two drawbacks/tricky problems right now:

• Not being able to use it as an AMD, CommonJS, or global module, but it feels like one should move away from those anyway if they are still used (except for CommonJS in Node I guess but the bundle size is not important in the same way there).
• Specifying which parts to include might be trickier than today if one wants to be very specific. And explicit exclusions would not be possible at all I guess.

I think this is definitely worth looking into. Thanks for the suggestion!

I'm interested in hearing what others think so please add your thoughts if you're reading this.

[madeleineostoja]

Any update or further thoughts on this? I would love the library to move in this direction, since I'm using it in a pnpm monorepo and I haven't been able to get the postinstall rebuild to work reliably / at all. And regardless of that issue, relying on a flexible architecture vs a custom build is a no brainer imo.

I'd advocate that the drawbacks listed are non-issues:

• Many popular libraries have moved to es-only, and I think a breaking version change for this one to do the same would be a positive rather than a negative. Most (all?) bundlers support es modules, and if you're not using a bundler then Node LTS and all evergreen browsers also support them
• If you're being very specific, how many bytes are you really saving? I think a more approachable API would easily win over supporting every edge case

[mattiasw]

No update but I do think about it now and then.

For saving bytes I think it's a common use case that the only thing you're interested in is e.g. date or GPS location. Then this new architecture could probably make the bundle 5+ times bigger. (I don't think it's manageable to have each Exif tag as a plugin, and the other types of metadata don't even have specific tags like that.) That doesn't mean it's a big enough reason not to make the change though.

Anyway, I've mostly been waiting for more thoughts on and interest in this (except for finding the time). Also, are there good examples of other libraries that do this type of thing? I can't think of any myself that has this kind of plugin architecture. All the ones that have good tree shaking behavior that I come to think of have a very different setup with more stand-alone modules.