Some encodings are very rare (e.g. utf7 and iso-2022-jp #60), so it's always a hard decision to include them in iconv-lite, as they add space and memory requirements. To make this choice simpler, it would be nice to add an extension mechanism that would make it easy to add them as separate npm packages.
[ ] Add addEncoding() function. It will by default check that the new package does not override any existing encodings/aliases. This behavior can be disabled by passing {replace: true} as a second arg. Function should be idempotent.
[ ] Extract utf7 as an example.
[ ] Create a test harness that would help authors make sure their codecs work on the whole range of supported environments.
Question: would it be better to use immutable-like interface iconv = iconv.withEncoding(require('...'));? It would help with testability, but overall I think it's not worth it, as users will have to either do it in every file that needs iconv, or pass it around in some kind of a global.
Some encodings are very rare (e.g. utf7 and iso-2022-jp #60), so it's always a hard decision to include them in iconv-lite, as they add space and memory requirements. To make this choice simpler, it would be nice to add an extension mechanism that would make it easy to add them as separate npm packages.
Something like this:
What we'll need:
addEncoding()function. It will by default check that the new package does not override any existing encodings/aliases. This behavior can be disabled by passing {replace: true} as a second arg. Function should be idempotent.Question: would it be better to use immutable-like interface
iconv = iconv.withEncoding(require('...'));? It would help with testability, but overall I think it's not worth it, as users will have to either do it in every file that needs iconv, or pass it around in some kind of a global.