[2.x] Generate Sourcemaps for Development Environment

[slavarazum]

Sourcemaps should be provided preferably for development environment to provide appropriate debugging experience.

In general, we shouldn't generate it and host on production because of 2 reasons:

1. Most projects under NDA, so we can't open our source code to public view.
2. Security purposes. We shouldn't open our source code to eliminate the possibility for malefactors to investigate the source code for founding vulnerabilities.

As a point you can check out Bugsnag docs which recommend uploading source maps directly to service - Uploading Source Maps and not recommends hosting them.

I see only one reason to host sourcemaps temporarily in production - debug a complex issue that appears only in production mode.

Sourcemaps needs not only for minified assets but for every build where debugging needs.

This is development build without sourcemaps:

It has only final app.js file which isn't minified, but totally not readable and debuggable because it has transpiled by webpack.

This is development build with sourcemaps:

It has webpack and webpack-internals directories which has our application source code structure with all components and JavaScript files where we can place breakpoints, evaluate expressions and other debugging purposes.

Conclusion:
We always should generate sourcemaps in development environment to provide appropriate debugging experience and usually shouldn't generate it in production.

P.S.: @taylorotwell, take a look into original discussion with @driesvints - #502

[driesvints]

Thanks @slavarazum

[taylorotwell]

Rails 6 ships source maps in production by default: rails/webpacker#769 (comment)

I plan to let people decide what they want to do on their own.

[slavarazum]

Ok, if source maps in production is a controversial question, but we always really need it in development the same as we have APP_DEBUG=true in .env.example by default.
Sometimes I really wonder how you make decisions. No discussions, no deep look, just close it.

Probably the most thankless job I've ever done is contributing to Laravel.

@driesvints Thanks for understanding my point.

[driesvints]

Tbvh it's still an opinionated topic. One could argue that everything's reverse engineer-able, even compiled assets. In that regard your front-end source code is always publicly available and the issue of uploading source maps is a non issue. I personally lean more to not including them in production after your thorough explanation of the topic but that doesn't mean my or your way needs to be the default. The files published here are owned by the app maintainer and can be modified however they see fit.

Ultimately it's up to Taylor to decide if he wants to merge this or not, or any maintainer for any OS project for that matter. That's how open source works. Besides, Taylor linked to a comment from @dhh that clearly explains his views on this.

[slavarazum]

@dhh told that view our source code in production it's pay tribute to the web in this fashion. Can we said that at the same point we always should open source our backend code? I know that front-end source code is always publicly available, and we could argue that everything's reverse engineer-able, but again it's discussion about source maps in production, my PR enables source maps only in development!

And I also know that files like webpack.mix.jscan be modified by an app maintainer in the own way. But here we try to give our community better experience by setting useful defaults.
I'm also open source maintainer and I know how it works. In exampled issue we can see a great discussion. It's not right open source when we have a single source of truth is Taylor's opinion.
It's open source in order to delegate some work to community and not for building something with community.

[driesvints]

I don't think you understand how open source works if you expect that a maintainer should always agree to outsider's opinions and merge things they don't want in the code they have to maintain. Taylor has a different opinion than yours and decided not to merge your PR. That's his right as the maintainer of this project. This does't has anything to do with "useful defaults" or "deligating work to the community".

[slavarazum]

If you reread my message, you will understand that it has nothing similar with "always agree to contributors".
When you are maintainer of an open source project, yes the final decision is yours, absolutely. But be respectful, try to understand a request, explain your opinion, start discussion on controversial topics than you can make your final weighted decision.
In this case I got the opinion about source maps in production and PR was immediately closed, I don't get how it related to changes in the PR.
It's sad that you call contributors as "outsiders", my main thought is that - If Taylor had been a little more respectful to the community Laravel would grow up stronger.