Support private source maps

[steren]

The library only supports source maps when:

• The minified file is appended with a comment directive to your source map file:

  //# sourceMappingURL=http://example.com/path/to/your/sourcemap.map

• And this file is publicly accessible.

Including server-side component, we could imagine a way to not need to make the source map available publicly.

[eriwen]

@steren I would like to support private source maps in stacktrace.js v2.0 and I want to design it in way that benefits this project.

I'm curious if the intent is for source map files to be available publicly, though obscured by omitting the sourceMappingURL directive; or if instead source map files should be locally accessible through a node-friendly tool.

Thank you for using stacktrace.js, and please let me know if there are other changes I can make to my project to enable the Google Cloud Platform.

[steren]

Hi @eriwen, thanks for reaching out and thanks for your tremendous work on stacktracejs.

I think the end goal should be for the source map file to never be accessible publicly.

For Stackdriver Error Reporting, the ideal scenario would be the following:

1. Source map files are generated when users compile their JS
2. At deploy time, these source map files are "sent to Google": a Google Stackdriver API endpoint is called using secure credentials (using gcloud auth or service accounts), the source maps can either be inside the POST request body, or be first uploaded to Google Cloud Storage and then referenced in the payload.
3. When reporting errors, the minified stack trace is sent to the "Stackdriver Error Reporting" report API endpoint.
4. Server-side logic, owned by Google Stackdriver, transforms this stack trace into an unminified stack trace, and continue with error processing like for any other error.

However, today, none of these pieces (2,3,4) exist and they are not at the top of the priority list.

The following scenario would be a good intermediate solution:

0. Users run an open source Node.JS application (ideally on a highly managed platform like Google App Engine, to avoid unecessary maintenance costs).
1. Source map files are generated when user compile their JS
2. At deploy time, these source map files are sent to be stored securely into Google Cloud Storage.
3. When reporting errors, the minified stack trace is sent by the stackdriver-errors-js client-side library to an endpoint of the server-side Node.JS application.
4. The Node.JS application unminifies the stack trace by accessing securely the source maps files (probably with some caching, since we do not want to read files in Cloud Storage for every reported error).
5. The Node.JS application then sends the unminified error to the "Stackdriver Error Reporting" report API endpoint.

This scenario is achievable using the Stackdriver features that are available today.

Some part of this Node.JS app are independent from Stackdriver Error Reporting, these could be the ones that make sense to be provided by stacktrace.js. Sending unminified errors to Stackdriver from this app could be an addition that stackdriver-errors-js provides.

What do you think?

[eriwen]

@steren Thanks very much for the kind words and the information — it makes a lot of sense.

It seems like my best next step would be to spike a Node.JS app that does what you describe and see if any functionality in stacktrace.js itself can help in a platform-agnostic way. The app can perhaps evolve into an official "stacktrace-to-stackdriver-adapter" or some examples to help users integrate stacktrace.js with Google Cloud Storage and the Stackdriver APIs.

I'm happy to take this next step over the coming weeks. Do you think that'd be a beneficial investment for you?

[steren]

Any step (first of third party) that would bring users closer to private maps support is very valuable for us.

We could keep the platform-agnostic part in stacktrace.js and the Stackdriver specific code in this repo (I would be glad to help you on this part).

Keep me in the loop

[maxbaluev]

any updates?

[steren]

Today, I have no plans to work on this.

[eriwen]

I intend to focus on stacktrace.js v2.0 in the month of March, and will consider this.

@steren are you still involved on this project given your new involvement with Bazel, or is there another I should work with if this is implemented?

[steren]

stackdriver-errors-js is an experimental project I developed on the side to provide a better support of client-side JavaScript apps.
Consider me still involved as a maintainer. I would be happy to upgrade it so use stacktrace.js 2.0 or to provide inputs for your design.

[vongohren]

@eriwen @steren this kinda stopped, but the lib is still updated, 6 days ago. Are there any thoughts for this feature?

[jer-tx]

+1

[langri-sha]

I understand a lot of dedicated service providers out there provide some endpoints where clients publish release information and the accompanying source maps.

Some of us may be using Cloud Build build and otherwise already have their build artifacts on Cloud Storage. So something that could also work on GCP is to provide the bucket URL to the source map.

[dulacp]

Another approach to this (used by Sentry.io for example) is to provide a token to stackdriver that will be used in a custom HTTP Header to authenticate stackdriver with the endpoint given in //# sourceMappingURL=... and access the sourcemap.

It seems a lot simpler to implement, what do you think?

[mohamedfasil]

Any update / plan to support this ?

[mohamedfasil]

Any update / plan to support this ?