How does the front end reproduce online problems locally?

My local is obviously good, right? Definitely a false positive!
Of course, most of this situation is your inner YY, and in fact there is a real problem.
After reading the reproduction path of QA, you try to reproduce locally, but you cannot reproduce locally.
The reason is due to the difference between live and local environment. There may be many reasons here. I understand the main two points as follows:

Data is different. The local data is more used in the test environment, and the data in the real environment used in live. Different data, page rendering and interaction may be different.
Packaging configuration is different. When the front end uses some packaging tools, such as webpack, it generally distinguishes between dev and prod environments. Different environments have different configurations. For example, the dev environment needs to enable hot updates, and the prod environment needs to do some code compression.

Deploy our packaged code locally using nginx

For the second point above, if we want to reproduce it, it is also very simple. We only need to run the code we built locally, right? Here we use nginx to locally deploy our packaged code.
The specific process of installing nginx, we will not discuss it here, please Google it by yourself. If it's a Mac and you have brew installed. as follows:
brew install nginx

The first step is to package your code.

The second step is to modify your nginx configuration file. For Mac it is /usr/local/etc/nginx/nginx.conf. Modify the configuration in the server root to point to the address where the packaged static files of your project are stored.
server {
listen 8080;
server_name localhost;

location / {
- root html/static;
# The address where the packaged static files of the project are stored
+ root /Users/guangpingfeng/Documents/shopee/projects/yapi;
index index.html index.htm;
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;

The third step is to start nginx. At this point, you can access your page through, which is consistent with the front-end packaging resources of the formal environment.
# start up

Other more commands about nginx:

Exit the service: nginx -s quit
Force shut down the service: nginx -s stop
Reload the service: nginx -s reload (restart, the service will not be terminated)
Verify the configuration file: nginx -t
Use configuration file: nginx -c
Use help: nginx -h

Is there something simpler - whistle

I won't introduce too much whistle here. If you are interested, you can read one of my previous articles - web debugging tools that the front end should know - whistle.
The idea of ​​using whistle is to use locally packaged resources to proxy online.
Take the example above. We hope that online access to static resources in the static/prd directory can access locally packaged resources. Only need to configure such a rule (I use for the domain names demonstrated here). whistle will automatically complete the local file path according to the remaining path of the matching url, and automatically ignore the following request parameters: file:///Users/projects/yapi/static/prd

For example, visiting will proxy to the local file:///Users/projects/yapi/static/prd/lib3@d380218b438aef3811b2.js
This is very useful, but sometimes, you will find that the packaged md5 strings are different, in which case you can use wildcard matching.
The matching pattern must start with ^ (if you need to limit the end position, it can be used), ∗ is a wildcard, supports pass), * is a wildcard, supports pass), ∗ is a wildcard, supports 0...9 to get wildcard matching strings, Where $0 represents the entire request url.
The rules for the above example can be expressed as follows:
^**.*.* file:///Users/projects/yapi/static/prd/$1.$3

When you visit, you actually visit file:///Users/projects/yapi/static/prd/index.js. (Note that at this time, the locally packaged code does not have md5).
Live data and local environment are different
In this case, the fastest way is to ask QA to copy the live data for me, and I directly proxy the data returned by the interface to the local request for reproduction. This can actually be achieved very simply through whistle, so I won't go into details.
In addition, we usually develop a service locally. When building with webpack, we are used to introducing webpack-dev-server as a memory static server, which provides a proxy to be responsible for a layer of proxy. By matching the back-end interface, Then point to the live environment through target.
proxy: {
'/api': {
target: `,
changeOrigin: true,
onProxyRes(proxyRes, _, res) {

In the same way, it can be solved completely with whistle, with one rule.

at last
Have you ever encountered, there is no problem locally, is there a problem online? How do you usually solve it? Hope this article can give you some ideas.
refer to

Implement map local with whistle
After the vue project is packaged locally, cross-domain is solved through nginx 🎉

Related Articles

Explore More Special Offers

  1. Short Message Service(SMS) & Mail Service

    50,000 email package starts as low as USD 1.99, 120 short messages start at only USD 1.00