Why do we need --minified-path-prefix?

[johnholiver]

Is your feature request related to a problem? Please describe: My problem is that my bundled files are deployed in different paths depending on a specific logic. Because of --minified-path-prefix, I need to share path details of where the bundle is served from, in other words, my uploader needs to be aware of the logic of how I organize/prefix the files, and I can't seem to find out why.

As an example, given a file js/x.js, in production it could be served from https://prod.cdn.organization.com/vanitazedApp/$version/js/x.js, while in staging it would be served from https://staging.cdn.organization.com/app1/$version/js/x.js. Consider the sample production URL. The hostname, the app folder, and the version folder that compose the path from which I serve my files are my implementation details. Which in my understanding is irrelevant for pattern matching js/x.js that will always be at the end of the URL.

Describe the solution you'd like: I'd like --minified-path-prefix to be removed, and path matching to be done automatically. I haven't found the 'backend' code that would justify datadog-ci consumers needing to manually provide match rules.

Describe alternatives you've considered:

• I've considered executing datadog-ci multiple times, pushing my files each time matching a path, so that I don't have to configure prefixes on the fly.
• I've considered only using upload sourcemaps on a single environment.

Additional context: On https://github.com/DataDog/datadog-ci/pull/131, the author removes the need to push a hostname as a prefix. It suggests that the backend is capable of partial URL matches. Yet, --minified-path-prefix=/ doesn't manage to match something such as https://prod.cdn.organization.com/vanitazedApp/$version/js/x.js to uploaded /js/x.js (tested and does not work). Apparently, we would need to give the entire path prefix that appears after the hostname, in this case /vanitazedApp/$version (tested and does work).

Finally, maybe one can point out why this parameter is necessary, showing the code path that is relevant.

[rpelliard]

Let me try to clarify the role of --minified-path-prefix: it allows specifying where the file will be hosted. This supports two different use-cases. Assuming there is a sourcemap in ./js/x.js.map, this option can be set:

• with a hostname - e.g. setting it to https://example.com/static/ will allow the sourcemap to be used to unminify stack frames from https://example.com/static/js/x.js
• without hostname - e.g. setting it to /static/ will allow the sourcemap to be used to unminify stack frames from any domain, i.e. <any hostname>/static/js/x.js.

At the moment, we only support matching full URL paths, and --minified-path-prefix is useful in case the files aren't hosted directly at the root of the domain.

Your use-case of having different path prefixes per domain is indeed not supported at the moment. This seems like a very valid use-case though, and indeed, if we start to support matching only suffixes for URL paths, --minified-path-prefix would probably no longer be required. We can leave this issue open to track the feature request.

As you suggested, at the moment the easiest workaround would be to upload the sourcemaps twice, both with --minified-path-prefix https://prod.cdn.organization.com/vanitazedApp/$version/ and --minified-path-prefix https://staging.cdn.organization.com/app1/$version/.

[Havunen]

Wouldn't it be possible to upload the same source map once with multiple prefixes? In our development workflow the same bundle gets first deployed to internal, then to staging and finally to production. The application is question is quite big, source maps is about 50MB...

[amezick]

@rpelliard I have run into a similar problem. We are using Salesforce Commerce Cloud (SFCC). The compiled JS gets placed into a directory named like this in production: https://HOSTNAME.com/on/demandware.static/Sites-COMPANY-Site/-/default/v1666031122200/js

The "v1666031122200" is determined by the SFCC backend and I have no control over how it is named or knowledge of what the name will be before the code is deployed. The only way for me to find this string is to view-source on a page.

[rpelliard]

@amezick Looks like matching the sourcemaps by path suffix instead of entire path would also solve your issue. Unfortunately, this still isn't supported, but we're tracking the feature request.

[brekt]

Chiming in here because we're also running into some complexity around this. We have a pipeline that deploys multiple apps with sourcemaps and assets that can live at a number of locations. Trying to assemble all those paths dynamically to get the minified-path-prefix right is a challenge.

We have it working for most environments, but for prod we have a deployment process where the sourcemaps and JS artifacts aren't available in the workspace when the pipeline runs because it uses previously built, tested, and published artifacts. I can hunt down and download those the artifacts from S3 during a prod deployment but I'm struggling to maintain all the varying relative pathing:

Uploading sourcemap downloaded-artifacts/file-hash.artifact.js.map for JS file available at https://static.my-cdn.net/complex/and/varying/path/file-hash.artifact.js // <-- this path is hard to get right dynamically

It seems like that logged path is affected by both the minified-path-prefix and where the sourcemaps and JS are sitting when the upload command runs.

It would be great if we could just upload the .js and .js.map files from either a flat folder or recursively and as long as the release-version matches the client side then the unminified code feature still worked. I appreciate this may be easier said than done.

[JiatangDong]

We have a similar problem. We build our javascript code once into a container and then deploy it to multiple domains. When we upload the source map in the build pipeline we need to specify multiple prefixes for all the domains. Supporting regex matching will solve this problem gracefully.

[thebrubaker]

I agree - regex matching would be quite nice!

[p-desaintchamas]

We have the same issue, and facing the 408 request several time while uploading both sources to production & preproduction. Would be nice to have this feature to reduce the time to upload sourcemaps by half.

[patryk-zielinski93]

We are facing the same issue right now. We have hundreds of instances with different path parameter for each instance, so uploading source maps multiple times is not an option. When we can expect regex path matching feature? Is this on development roadmap?

[janowak]

Same scenario for us - as we use dynamic prefix we can't use sourcemap for our application