[BUG] Sourcemap load errors in debugger from @nevware21 dependencies

[johncrim]

Description/Screenshot

Every time I run Angular apps in a debugger, with app insights dependencies, I get a long spew of source map failure lines, like

This is not impacting runtime behavior, but it is a large amount of warnings/errors that can obscure useful errors. This occurs both in browsers and VS Code debuggers.

Some of the text:

Could not read source map for file:///C:/src/co/webui/node_modules/%40nevware21/ts-async/build/es5/mod/internal/constants.js: ENOENT: no such file or directory, open 'c:\src\co\webui\node_modules\@nevware21\ts-async\build\es5\mod\internal\constants.js.map'
Could not read source map for file:///C:/src/co/webui/node_modules/%40nevware21/ts-async/build/es5/mod/promise/await.js: ENOENT: no such file or directory, open 'c:\src\co\webui\node_modules\@nevware21\ts-async\build\es5\mod\promise\await.js.map'
Could not read source map for file:///C:/src/co/webui/node_modules/%40nevware21/ts-async/build/es5/mod/promise/debug.js: ENOENT: no such file or directory, open 'c:\src\co\webui\node_modules\@nevware21\ts-async\build\es5\mod\promise\debug.js.map'
Could not read source map for file:///C:/src/co/webui/node_modules/%40nevware21/ts-async/build/es5/mod/internal/state.js: ENOENT: no such file or directory, open 'c:\src\co\webui\node_modules\@nevware21\ts-async\build\es5\mod\internal\state.js.map'
Could not read source map for file:///C:/src/co/webui/node_modules/%40nevware21/ts-async/build/es5/mod/promise/event.js: ENOENT: no such file or directory, open 'c:\src\co\webui\node_modules\@nevware21\ts-async\build\es5\mod\promise\event.js.map'
Could not read source map for file:///C:/src/co/webui/node_modules/%40nevware21/ts-async/build/es5/mod/promise/base.js: ENOENT: no such file or directory, open 'c:\src\co\webui\node_modules\@nevware21\ts-async\build\es5\mod\promise\base.js.map'
... (then more in ts-utils)
Could not read source map for file:///C:/src/co/webui/node_modules/%40nevware21/ts-utils/build/es5/mod/internal/constants.js: ENOENT: no such file or directory, open 'c:\src\co\webui\node_modules\@nevware21\ts-utils\build\es5\mod\internal\constants.js.map'
Could not read source map for file:///C:/src/co/webui/node_modules/%40nevware21/ts-utils/build/es5/mod/helpers/safe.js: ENOENT: no such file or directory, open 'c:\src\co\webui\node_modules\@nevware21\ts-utils\build\es5\mod\helpers\safe.js.map'
Could not read source map for file:///C:/src/co/webui/node_modules/%40nevware21/ts-utils/build/es5/mod/helpers/safe_get.js: ENOENT: no such file or directory, open 'c:\src\co\webui\node_modules\@nevware21\ts-utils\build\es5\mod\helpers\safe_get.js.map'

There are about 100 lines of such errors each time the app is started in the debugger.

Steps to Reproduce

Angular starter project, including and using dependency:

    "@microsoft/applicationinsights-web": "^3.3.2",

• OS/Browser: Windows 11, VS Code Version: 1.93.1
  OS: Windows_NT x64 10.0.22631
• SDK Version [e.g. 22]: 3.3.2
• How you initialized the SDK: irrelevant - the files just need to be linked

Expected behavior
No errors and sourcemaps working.

Additional context

Note that the issue isn't that the @ char is escaped to %40 - the issue is that the /build/ dir isn't present in the @nevware21\ts-async and @nevware21\ts-utils packages.

For example, the @nevware21\ts-async\bundle\es5\ts-polyfills-async.js.map file contains this:

{"version":3,"file":"ts-polyfills-async.js","sources":[
"../../../common/temp/node_modules/@nevware21/ts-utils/dist/es5/mod/ts-utils.js",
"../../build/es5/mod/internal/constants.js","../../build/es5/mod/promise/await.js",
"../../build/es5/mod/internal/state.js","../../build/es5/mod/promise/event.js",
"../../build/es5/mod/promise/base.js","../../build/es5/mod/promise/itemProcessor.js",
"../../build/es5/mod/promise/asyncPromise.js","../../build/es5/mod/polyfills/promise.js",
"../../build/es5/mod/polyfills.js"
],
"sourcesContent":["/*! https://github.com/nevware21/ts-utils v0.11.3 */\n/*\n * Copyright (c) NevWare21 Solutions LLC and contributors. All rights reserved.\n *

which I believe is the source of the incorrect reference to the build dir for the sourcemaps.

[MSNev]

This seems like a issue with the way your build system is creating your map files?

@nevware21\ts-async\bundle\es5\ts-polyfills-async.js

The Application Insights SDK doesn't actually use this file and you don't need to use this file as internally the ts-async automatically uses it's internal polyfills (if required) without explicitly importing this module.

The provided map files for Application Insights and the ts-async are provided purely for when using the components from the CDN and not when you are using npm integration as the provided map files become meaningless within your bundles....

[MSNev]

Another comment on the reference (which may just be an example that you have provided, but calling out for anyone else who may see this).

Unless you know you are running (or may run) in an environment that does not support Promise capability AND you are not providing your own PolyFills you don't need to use ts-polyfills-async.

IF you are just using ts-async, you can avoid importing / including ts-polyfills-async by just using ts-async and it's helper functions createPromise (etc). The only "addition" that ts-polyfills-async provides is that when the runtime doesn't contain a global Promise is provides one so that code not directly using ts-async can continue to use the ES Promise functions.

[johncrim]

Hi @MSNev - thanks for the review.

I'm not declaring the problematic dependencies nor creating the map files - though they do get combined when the js files are bundled. In node_modules\@microsoft\applicationinsights-channel-js\package.json:

{
    "name": "@microsoft/applicationinsights-channel-js",
    "version": "3.3.3",
    "description": "Microsoft Application Insights JavaScript SDK Channel",
    "homepage": "https://github.com/microsoft/ApplicationInsights-JS#readme",
    "author": "Microsoft Application Insights Team",
    "main": "dist/es5/applicationinsights-channel-js.js",
    "module": "dist-es5/applicationinsights-channel-js.js",
...
    "dependencies": {
        "@microsoft/dynamicproto-js": "^2.0.3",
        "@microsoft/applicationinsights-shims": "3.0.1",
        "@microsoft/applicationinsights-core-js": "3.3.3",
        "@microsoft/applicationinsights-common": "3.3.3",
        "@nevware21/ts-utils": ">= 0.11.3 < 2.x",
        "@nevware21/ts-async": ">= 0.5.2 < 2.x"
    },

And from node_modules\@nevware21\ts-async\package.json:

{
    "name": "@nevware21/ts-async",
    "version": "0.5.2",
    "homepage": "https://github.com/nevware21/ts-async",
...

    "esnext:main": "dist/es6/main/ts-async.js",
    "module": "dist/es5/mod/ts-async.js",

The map file that node_modules\@nevware21\ts-async\dist\es5\mod\ts-async.js points to is node_modules\@nevware21\ts-async\dist\es5\mod\ts-async.js.map, and it contains this:

{
  "version": 3,
  "file": "ts-async.js",
  "sources": [
    "../../../build/es5/mod/internal/constants.js",
    "../../../build/es5/mod/promise/await.js",
    "../../../build/es5/mod/promise/debug.js",
    "../../../build/es5/mod/internal/state.js",
    "../../../build/es5/mod/promise/event.js",
    "../../../build/es5/mod/promise/base.js",
    "../../../build/es5/mod/promise/itemProcessor.js",
    "../../../build/es5/mod/promise/asyncPromise.js",
    "../../../build/es5/mod/promise/nativePromise.js",
    "../../../build/es5/mod/promise/syncPromise.js",
    "../../../build/es5/mod/promise/idlePromise.js",
    "../../../build/es5/mod/promise/promise.js",
    "../../../build/es5/mod/promise/timeoutPromise.js",
    "../../../build/es5/mod/helpers/doWhileAsync.js",
    "../../../build/es5/mod/helpers/arrForEachAsync.js",
    "../../../build/es5/mod/helpers/iterForOfAsync.js",
    "../../../build/es5/mod/scheduler/taskScheduler.js",
    "../../../build/es5/mod/polyfills/promise.js"
  ],

which are references to JS files that don't exist in the NPM package.

[MSNev]

Ah..., I understand now...

Because we are creating "single" export definitions (which are referenced in the package.json as the input) and they are using rollup to "package" the content, this is including a map file reference at the bottom of the file for each of their local builds....

So that when you "consume" these bundles it causes those references to get referenced / used as well -- let me look into how to get these removed as thats unexpected and annoying (nice that it links back to the original TS files, but not the expected outcome when consuming via npm).

[MSNev]

Hmm, for the specific node_modules reference this looks like it might be a bug in rollup as according to this documentation if we don't specify anything then all files with node_modules are supposed to get ignored... Still investigating.

[nev21]

@johncrim Can I assume that your generated sourcemap for the included bundle does not include the sourcesContent? Which is why the dev console is / needs to fetch the file based on the sources array?

I believe that I've addressed this for @nevware21/ts-utils (still need to apply a similar / same change to @nevware21.ts-async and then Application Insights will (probably) also need to do the same type of thing.

[johncrim]

Hi @nev21 / @MSNev - it looks like the generated sourcemap for the bundle (which includes app insights and nevware files) includes both sources and sourcesContent. I can upload the generated sourcemap file if that helps.

We use standard Angular builds, so nothing fancy or custom in the bundling. Interestingly our angular dependencies also include references to source files that aren't included in the node_modules, so now I'm questioning whether my diagnosis was correct (I was just correlating the error messages that appear every time with the links in the source maps). For example, here's the start of an angular CDK source map:

# from node_modules\@angular\cdk\fesm2022\stepper.mjs.map
{"version":3,"file":"stepper.mjs","sources":["../../../../../../src/cdk/stepper/step-header.ts","../../../../../../src/cdk/stepper/step-label.ts","../../../../../../src/cdk/stepper/stepper.ts","../../../../../../src/cdk/stepper/stepper-button.ts","../../../../../../src/cdk/stepper/stepper-module.ts","../../../../../../src/cdk/stepper/stepper_public_index.ts"],"sourcesContent":["/**\n * @license\n * Copyright Google LLC All Rights Reserved.\n *\n * Use of this source code is governed by an MIT-style license that can be\n * found in the LICENSE file at https://angular.io/license\n */\n\nimport {Directive, ElementRef} from '@angular/core';\nimport {FocusableOption} from '@angular/cdk/a11y';\n\n@Directive({\n  selector: '[cdkStepHeader]',\n  host: {\n    'role': 'tab',\n  },\n  standalone: true,\n})\nexport class CdkStepHeader implements FocusableOption {\n  constructor(public _elementRef: ElementRef<HTMLElement>) {}\n\n  /** Focuses the step header. */\n  focus() {\n    this._elementRef.nativeElement.focus();\n  }\n}\n","/**\n * @license\n * Copyright Google LLC All Rights Reserved.\n *\n * Use of th  ...

The references sources aren't included in the node_module. Obviously this is different in a few ways - it's an .mjs file and the references are .ts files, so the sourcemap processing could be different.

I don't have time today, but I can set up a repro project so you can see the error. I'm pretty sure a basic angular project that uses app insights will do it.

[MSNev]

Yeah, I'm working on fixing the AI stuff for our final release of the year next week. But one thing I've noticed with the changes to ts-utils is that our rollups are now including relative paths before the http:// that now exists?? So rollup is doing something funky.

I'm also going to adopt the same "sourcemap" reference that was added to ts-utlis to get the "real" *.ts references rather than the *.js that it's currently producing