Providing a way to have protected sourcemaps in production

[hugo-dlb]

In recent changes, sourcemaps were no longer shipped in the production static assets.
This means it's pretty hard to debug code on production even if Sentry helps to some extent since sourcemaps are uploaded there.
It would be nice to introduce back sourcemaps in production (off by default to keep the current behavior) in a way that is restrictive.

Here are some possible improvements based on these Discord messages:

1. Leverage the upcoming middlewares API to allow or deny access to sourcemap static assets
   As I understand it middlewares would only work at the route level (and not for static assets) so this would require support from the Remix team?
2. Create an express middleware that would need to work along the express static middleware which would allow access to all files ending by .js.map conditionally (e.g. by reading cookies and returning a boolean)
   This middleware could then be used inside the Remix server and one of the parameters exposed could look like this:

{
    sourcemapsMiddlewareAccessFn?: (req: Request) => boolean
}

3. Provide a guide to load sourcemaps manually when needed by using the dev tools (e.g. here for Chrome)
   Currently each js file seems to have its own sourcemap so it might be tedious to add hundreds of sourcemap files. A change to have a single sourcemap for all files would be needed in the esbuild config
4. Keep the current setup and leave it up to the developers to make changes that suit their needs

Let me know what you think about the idea and the proposed improvements!

[kentcdodds]

I'm definitely open to ideas here. This is tricky because you don't want to limit the sourcemaps to people who have a specific role or anything because maybe the thing you're debugging is only available when you're not authenticated. So we need to think of a way to validate that the user should have access to the source maps.

[kiliman]

I'm still working on the tool to strip all the server code from the client source maps.

I found a better AST library: ts-morph. I've also changed my strategy from removing server code, to only including client code (code referenced from client exports). It will also strip out comments that are not inside a client function.

Doing it this way, I believe, will be much safer.

[kentcdodds]

Ah yeah, this would probably be a better UX as well. I hope this works out!

[hugo-dlb]

I thought one approach would be to (manually) set a cookie containing some build hash that is generated on every build. If you're a developer, you should have access to this value by looking at the pipeline logs, assuming they are still available...
And have some rate limiting in place if this cookie is sent along the request to prevent bruteforcing just in case.

Interesting challenge @kiliman ! I think your efforts could also benefit these suggestions for an extra layer of security and reduce the sourcemap sizes.

[sergiodxa]

One way to do this, could be to create a route that matches all source map files, then authorize the request somehow (maybe a cookie you can set manually in your browser?) and finally return the actual source map from the file system.

[hugo-dlb]

Definitely, that's along the lines of the second option! I added a comment above that goes in this direction