I'm deploying my website - a static site built in GatsbyJS - and my sourcemaps are by far my largest files. I have 3 sourcemap files that are ~ 3MB. Overall they make up maybe 70% of my build.
Should I deploy them to my production server?
Are sourcemaps only downloaded by users that open devtools?
Considering what a source map is you just need to take into account that:
If they are served publicly users can get access to your source code (only if source map files are requested with the proper tools, of course).
Need more disk space (in your case ~3 MB)
But, of course, you might need them on production mode in case you need to debug your application (on production mode, since they are not needed for debugging purposes on development mode) (See Source maps files in production - Is it safe? and Why use source maps in production?).
So, this decision is completely up to you according to your needs and requirements, having in mind the previously mentioned points.
Related
In a production environment, where my javascript assets are bundled, when there is a javascript error that I catch, I get with it the line and column, for example:
d86c04c8f3.js:2:9588
Now, since the file is minified, etc., it's difficult to reverse-engineer and find the problematic line in the source code. Do the rails assets bundler has a way to reverse engineer, given the line/col to find the original line? It should be possible, since the asset-builder has all the information it needs.
We need a simple option, to run the
bundle exec rake assets:precompile RAILS_ENV=production
again, but this time specify line+col, and then the rake will output what is the source file + line which corresponds to that asset line+col. This way we can easily debug exceptions that are being catched on the client side (and that are sent to the server for monitoring purposes).
EDIT1
All the solution regarding doing something on the client side are infeasible, since we don't have access to the client - we're talking about exceptions that were discovered in production mode, live mode, and that are being sent to the server for monitoring purposes.
For debugging minified scripts there're sourcemaps, once loaded in browser - you can see unminified code there.
Sprockets planned support for sourcemaps in 4.0, which is still not released yet (only a beta).
Webpack does support sourcemaps and rails 6 switched to webpacker by default, so converting scripts to packs seems logical, albeit being a massive task for large projects
Update: once you have source map for your build, you can use a tool like:
npx source-map-cli resolve d86c04c8f3.js.map 2 9588
This will tell you where in your code that position in minified file maps in the form of:
Maps to webpack:///app/javascript/components/CountrySelector.jsx:14:0
fetch(`/control/autocomplete/countries`).then(r => r.json()).then(countries => this.setState({countries}))
^
What is the need for bundle.js for Node.js/Angular/React applications? What if its not used while building and deploying the application?
Where bundling comes from?
We started bundling our assets because of performance reasons.
HTTP1 supports limited requests on a single connection. Creating connections for each asset was killing the performance.
We started bundling things page by page to increase performance with more effective caching.
We were able to add the fingerprint to it and upload it to a CDN. (home-page.231434.js). So we were able to deploy our application by dockerizing it.
Bundling also helps us reduce the page size more because the bundler knows the full system. This means it can remove unused things and minify things easier. You can't do it without a bundler easily.
Also, bundlers are using transpilers. Browsers can't always be able to run the codes that we write like Typescript, and CoffeeScript. Bundlers can transpile these codes easily into bundles.
Do we still need it?
Nowadays things are changed a lot about bundling our assets.
First of all, almost every browser now supports HTTP/2. So we can request multiple files on the same connection. Bundling is not needed because of this anymore. Also, we have http/2 server push.
Libraries like React, Angular, and Vue are a lot more effective in size. They can be easily downloaded to a page from a gzip supporting source.
These are the reasons we don't need bundling anymore.
But based on your project we may still need bundling. This is the real truth.
I would still go with bundling.
In my company, we are using a container orchestration system to control our dockerized applications. We may run more than a version same time. Creating fingerprints for files while bundling and uploading them to CDN is still more effective for us. And also we are trying to get use of prefetching and preloading. CDN helps us reduce the loading times of other country visitors.
And also we are getting support from the service worker to change assets when we need it by page.
So actually nowadays it is just based on your project. There are not many performance reasons anymore.
how to create bundle.js
Nowadays,we usually use pack tools like webpack to pack js、css or other files.With proper loaders, webpack will pack the files into many bundle files and the browser will understand them.
the need for bundle.js
The module bundler will analysis the project ,find the dependency relationship and only fetch the necessary package when loading the web page.
And with module bundler, it will compiler some lanuages that browser can't read, like typescript 、less and so on.
What if its not used
Module bundler is not necessary for web project, but it will improving the performance of web pages.If not using the module bundler, web can't only fetch necessary bundle when loading.So the loading time will be longer.
I am working on an AngularJS web application. I used uglify and minify to create vendor.js and app.js files but they are incredibly huge - 2 MB and 720KB respectively. As I see in Chrome Dev tools, they took 25s and 14s respectively to download which I think is a lot of time on my 100MBPS internet connection. I am worried about customer experience who might have far less speed than this. What are ways to compress or reduce the size of these files ? I believe vendor.js cannot be broken down because Angular needs all of it on the first page.
The biggest and quickest wins will be serving the files with gzip compression and on a CDN(cloudfront, akamai, etc). The CDN will usually serve the files from a location that is physically closer to the user(quicker to download). Most CDN's make it easy to enable gzip and that is probably where you will get your biggest win on file size.
After that you could look at tree-shaking. This may require a lot of refactoring if you aren't already using something to bundle your javascript like webpack. But the nice thing with tree-shaking is that it will exclude any code that you aren't using from your app.js and vendor.js files.
And finally you could look at lazy loading. This way you bootstrap your app with the minimum amount of code needed and as the user navigates to different parts of the app they download what they need. ocLazyLoad tends to be the popular choice if you are on 1.x: https://oclazyload.readme.io/
In my web app I was using RequireJS to asynchronously load my javascript files on demand. This worked well for dev - when debugging my app I could see which script is dependent on which and order in which they were loaded. This simplified debugging.
Later I switched to Webpack as it is much easier in configuration and easier to maintain. So Webpack now generates for me nice bundles containing my javascript code. This works perfectly well but what I'd like to have is an imitation of my previous RequireJS configuration for dev time.
When I am developing my app I want Webpack to generate some simple entry point (just like in RequireJS) which would load my javascript files one by one through their "require" references.
At the same time I still want that Webpack performed normal bundling when I deploy my app to a server.
Is this possible to achieve?
Enable Devtools in webpack.config.js to control and generate source maps (Source Maps enhance debugging process).
webpack.config.js
devtool: "#inline-source-map",
Chrome Debugger View
Nope, that's not possible. But have you tried the devtool-option? It maps back your original files in your devtools so you should see no difference whether the modules were in different files or just all in one.
New to WebStorm and trying to configure for an upcoming project. I want to exclude library files when debugging (Version 10).
I have the debugger connecting to the site running on chrome, as it is served by a local instance of nginx. I have used Settings >> Build, Execution and Deployment >> Debugger >> Stepping to set the paths of files I don't want to step into. I have tried relative paths, absolute paths and even the the http url paths. No matter what I try, the debugger always seems to step into library code.
Is there any trick to this? Can anyone at least confirm this feature is working for them?