the namespace inherited from the onLoad hook (which gets inherited from the onResolve hook).
the loader that is supposed to be used for this contents for the transformation.
any url-suffix string that is present in the path (including the leading question-mark "?" symbol).
an empty string represents the lack of any url-suffix.
the loaded content that is to be transformed.
the plugin data returned by the onLoad hook.
esbuild strips away any plugin-data when it resolves/loads natively.
hence, in order to preserve it during native loading,
we might have to instill a "file" namespace loader that will capture all native loading cases,
and then perform the loading ourselves, followed by preserving the plugin-data.
TODO: actually, right now, I'm intentionally stripping away the pluginData in my "native loader".
I'll have to see how much of an inconvenience it becomes before I give in to preserving the plugin-data.
otherwise, if I can manage to write plugins without needing this feature, then there's no reason to add it.
the resolveDir (used for node-resolution) returned by the loader.
when the onLoad hook function returns an empty/undefined resolveDir, this value turns into an empty string.
the with attribute argument passed to the onLoad hook.
dictates if OnTransformCallback function is being invoked by a call from SuperPluginBuild.transform. this is useful if your plugin is caching certain information, but you would like to only cache for actual incoming loaded resources, and not those that originate arbitrarily from elsewhere.
true, it means that your OnTransformCallback function is being invoked by a call from SuperPluginBuild.transform.false, it means that your OnTransformCallback function is being invoked by an actual the incoming loaded resource.
the resolved path of the contents.