Hi, I would suggest to change the Cordova overwrites to add CDV at the beginning, like CDVFile, CDVFileReader, this could be done in a major. I think it’s no problem for exisiting code, since they will work still when not upgrading and upgrades are not necessary currently for the file plugin to function further. It’s a breaking change and to change existing code to use CDVFile instead of File, is not a big change I guess.
Regards, Manuel Von: Norman Breau via dev <[email protected]> Datum: Dienstag, 3. November 2026 um 19:55 An: [email protected] <[email protected]> Cc: Norman Breau <[email protected]> Betreff: [DISCUSS] cordova-plugin-file Changing the JS clobbers to not overwrite standard browser APIs This is the beginning of a discussion thread. A vote thread will be created later in the week to form a final code modification consensus vote as per Apache Voting guidelines (https://www.apache.org/foundation/voting.html). That is at least 3 +1 must be present and no -1 vote must be present. A -1 vote is considered a veto. This discussion is a response of a desire to change the clobber path of the JS modules, to namespace them away from standard browser APIs, as discussed at https://github.com/apache/cordova-plugin-file/issues/316 The file plugin was created to overwrite and to provide an implementation based on a W3C spec that is now defunct -- however some parts of the W3C spec lives actively and browsers (and webviews alike) implements a good part of the File API, including `File`, `FileReader`, and `ProgressEvent`. The W3C spec has evolved and the file plugin hasn't kept up with modern features. For example, in a standard browser, `File` is an instanceof `Blob` and the native `File`/`Blob` are frequently used with wide scope of browser APIs such as XMLHttpRequest/fetch. The cordova implementation however is simply an object, an object whose API signature have sinced diverged from W3C and are otherwise incompatible with the aforementioned browser APIs. Because the standard file API is a extension of Blob, the standard file API also has several methods including `arrayBuffer()`, `stream()`, `textStream()`, all of which the cordova implementation lacks. This is primarily a pain-point in libraries that conducts a `instanceof` check since any references of `window.File` after cordova-plugin-file is loaded is referencing the plugin's implementation rather than the standard browser API. Workarounds available are limited. If you control the parts that wants to use the native browser API, then you can retain the reference of the standard API before cordova-plugin-file loads and then use the alternate reference point. This workaround falls apart if you're integrating with a third-party library or SDK. It's worth mentioning that the file plugin is a bit unique in that, it's functionality can be transiently used not only by cordova apps, but other plugins or libraries due to the file plugin's low-level API nature. There are 74 dependents listed on NPM, which would include variety of different apps, plugins or libraries that explicitly depends on cordova-plugin-file in their package.json in at least 1 published version. We'd have to also consider packages that depend on the file plugin but is not explicitly listed in the package.json, because cordova plugins dependency system primarily uses plugin.xml instead. Lastly, there is of course an unknown number of packages that are private and not publicly accessible and while we would never know the exact count I think we can safely assume it's above 0. NPM records roughly 50k weekly downloads on an eye-ball average. Therefore, we can expect a rather wide surface area of implications by changing the clobber namespace, not only from user apps but reasonable potential of breakage of existing plugins within the ecosystem. To refrain from writing a novel, I'll end the initial post here -- I'm sure there will be questions and comments that we can dive into. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
