Is it possible to have crossorigin attribute when loading ArcGIS modules?

[StreetStrider]

Hello, I'm not sure is this related to esri-loader especially, but this is related to ArcGIS JS in general. If this is not the proper place for a ticket, please, give me right direction.

Expected behavior

We use esri-loader + arcgis modules in JS and we want to receive detailed information on errors when they originate from arcgis. In order to have that we need proper CORS info set up and crossorigin=anonymous attribute for arcgis scripts. Using devtools Network tab I can tell that js.arcgis.com domain already sending proper access-control-allow- headers and we've already set crossorigin=anonymous for our arcgis entry point and esri-loader. But the modules which is loaded asynchronously by loader itself does not feature that attribute. That means for us that if error is originating from one of arcgis modules (which potentially might be the case) we would lost stacktrace information and other error details. Is it possible for ArcGIS system to set crossorigin=anynomous for loaded modules?

We use <script src="https://unpkg.com/esri-loader" crossorigin="anonymous"></script> and <script src="https://js.arcgis.com/4.14" crossorigin="anonymous"></script>.

Actual behavior

We receive some cryptic errors in our telemetry, they look like ScriptError or RangeError: maximum call stack size exceeded without actual callstacks. Since our own errors got detailed info, our best bet is that non-detailed errors are caused by code from third party domains (or at least some of them). This is in agreement with MDN docs.

Steps to reproduce the behavior

There's no precise reproduction, since I'm expecting some errors which does not available on demand. But scenario in general would be: include esri-loader and arcgis and load some gis component. The loaded modules would not feature crossorigin=anonymous attribute, because they loaded as a result of dependency resolving by arcgis itself.

[andygup]

Hi @StreetStrider the short answer is no, there aren't any guaranteed client-side workarounds for this issue. We don't have any plans to change the behavior in the AMD CDN build. For troubleshooting, one suggestion is to tell Chrome to stop at all errors.

The only definitive fix would be to upgrade/migrate to @arcgis/core ES modules at some point.

[StreetStrider]

We don't have any plans to change the behavior in the AMD CDN build.

I see. This is considered to be a legacy build, if I'm right.

Actually I thought I would be able to workaround this by myself, by monkey patching loader here. But it seemes that this is not the only place that creates script elements, there's another place inside modules that comes from arcgis itself.

My last resort is to try to use mutationobserver / setinterval to put crossorigin attribute to loaded scripts, but it might not work and seemes quite tricky for my goal.

one suggestion is to tell Chrome to stop at all errors

I can't, because this is no local development. We receive this via our error tracking from live client browsers. Actually we would like to have such errors on developer machines, and we try to unmask them to make them reproducible locally.

[andygup]

But it seemes that this is not the only place that creates script elements, there's another place inside modules that comes from arcgis itself.

Right, you could potentially monkey patch require.injectUrl but it comes with the same challenges and caveats: https://github.com/dojo/dojo/blob/master/dojo.js#L1746

[StreetStrider]

I've tried to use @arcgis/[email protected] and got this error:

WARNING in ../../node_modules/@arcgis/core/core/workers/workers.js 5:863-872
Critical dependency: the request of a dependency is an expression

As it seemes through the code, arcgis/core uses dynamic imports with variable. Is it possible to consume arcgis/core by webpack alone or do I need some special plugin to assist?

[odoe]

That webpack warning can be ignored, it has no impact on build tooling. You can turn them off in webpack here. https://webpack.js.org/configuration/stats/ There is no special plugin needed for @arcgis/core, but this is outside the scope of this repo.

[StreetStrider]

@odoe thank you for answer.

but this is outside the scope of this repo

Understood. I expected it to be so. Where is the better place to address arcgis/core related questions?

[odoe]

The resources repo might be a better place. https://github.com/Esri/jsapi-resources/

[andygup]

Closing as won't fix.