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]
