feat: improve production debugging dx

[pi0]

Types of changes

• Bug fix (a non-breaking change which fixes an issue)
• New feature (a non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Description

Resolve SSR stack trace paths

(outputs modified for readability. consola has a fancy logger that does some similar magic but only for display)

Old:

ReferenceError: crashme is not defined                                                                                                                                      16:07:17
    at asyncData (examples/hello-world/pages/index.vue:13:0)
    at promisify (examples/hello-world/.nuxt/utils.js:259:0)
    at server.js:1:<col>
    at Array.map (<anonymous>)
    at module.exports.__webpack_exports__.default (examples/hello-world/.nuxt/server.js:227:0)

New:

ReferenceError: crashme is not defined                                                                                                                                      
    at asyncData ([path]/examples/hello-world/pages/index.vue:13:0)
    at promisify ([path]/examples/hello-world/.nuxt/utils.js:259:0)
    at [path]/examples/hello-world/.nuxt/dist/server/server.js:2582:23
    at Array.map (<anonymous>)
    at module.exports.__webpack_exports__.default ([path]/examples/hello-world/.nuxt/server.js:227:0)

Make chunk names easy to debug

Old:

├── client
│   ├── 421fcb3837a373bcc316.js
│   ├── 43f6a8fec12d37fd9731.js
│   ├── 923c20ce304abf61b7d0.js
│   ├── f4d7116a13cbd5bad38e.js
│   ├── fb4666c8451b74cab31e.js
│   └── LICENSES
└── server
    ├── 7250d0198e376567f352.js
    ├── ae78742f8bb4962f2610.js
    ├── client.manifest.json
    ├── index.spa.html
    ├── index.ssr.html
    ├── server.js
    └── server.manifest.json

New:

├── client
│   ├── app.43f6a8f.js
│   ├── commons.app.f4d7116.js
│   ├── LICENSES
│   ├── pages
│   │   ├── about.923c20c.js
│   │   └── index.421fcb3.js
│   └── runtime.e630eac.js
└── server
    ├── client.manifest.json
    ├── index.spa.html
    ├── index.ssr.html
    ├── pages
    │   ├── about.js
    │   ├── about.js.map
    │   ├── index.js
    │   └── index.js.map
    ├── server.js
    ├── server.js.map
    └── server.manifest.json

Also, server.js is no longer minimized by terser. This helps making build little faster and also having correct sourcemap lines.

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly. (PR: #)
• I have added tests to cover my changes (if not applicable, please state why)
• All new and existing tests are passing.

[lihbr]

This is so cool, hope it'll land on time for 2.13.x 👏

[codecov-commenter]

Codecov Report

Merging #7463 into dev will decrease coverage by 0.05%.
The diff coverage is 88.09%.

@@            Coverage Diff             @@
##              dev    #7463      +/-   ##
==========================================
- Coverage   70.28%   70.22%   -0.06%     
==========================================
  Files          88       88              
  Lines        3708     3714       +6     
  Branches     1011     1008       -3     
==========================================
+ Hits         2606     2608       +2     
- Misses        894      898       +4     
  Partials      208      208              

Flag	Coverage Δ
#unittests	70.22% <88.09%> (-0.06%)	⬇️

Impacted Files	Coverage Δ
packages/webpack/src/config/server.js	2.27% <0.00%> (-0.11%)	⬇️
packages/server/src/middleware/error.js	95.23% <91.17%> (-3.07%)	⬇️
packages/config/src/config/build.js	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2abbb99...5cf9634. Read the comment docs.

[pimlie]

@pi0 Is there a measurable difference in parsing/loading server.js if not minimized? When you run a node server then that shouldn't matter much, but if you are using a lambda then that server.js could need to be parsed on almost every request.

[pi0]

@pimlie Agree however we are not currently officially supporting serverless target. Builders/Packers may utilize a minimizer to reduce size. I added build._minifyServer to make it easier until we improve support wdyt?

[pimlie]

As long as its still configurable I am happy, thanks ;)

[OrkhanAlikhanov]

@pi0 Is there any way to disable this? My routes are deep and it seems with this change file urls get even deeper I think I am running into SplitChunksPlugin truncating filenames.

Here is my file tree:

pages/
├── current-item
│   ├── _n.vue
│   └── index.vue
├── current-item.vue
├── dashboards
│   ├── _dashboardId
│   │   ├── items
│   │   │   ├── _itemId
│   │   │   │   ├── details.vue
│   │   │   │   └── youritems
│   │   │   │       └── _youritemId.vue
│   │   │   ├── _itemId.vue
│   │   │   └── index.vue
│   │   └── index.vue
│   └── _dashboardId.vue
......

Examples of long urls that nuxt generated but have been truncated:

vendors.pages/current-vendors.pages/current-item/[_]n.pages/dashboards/[_]dashboardId/items/_itemId/youritems/_youritemId..4d40e1ae.142e679.js

vendors.pages/dashboards/[_]dashboardId/items/_itemId/details.pages/dashboards/[_]dashboardId/items/.9ad5534e.e5bd853.js

Nuxt is unable to load last url in the example, when I try to access it it responds with /* script not found */ message. If I however rename it from .9ad5534e.e5bd853.js to a.9ad5534e.e5bd853.js it is loadable.
I don't know why vendor.pages nest files that much deep. Maybe cyclic dependency thing?

What do you think?

[pi0]

Hi @OrkhanAlikhanov. It had to be fixed with #7603 but seems [_] is preserved. As a temporary fix you can use:

build: {
  filenames: { 
    chunk: '[contenthash:7].js'
  }
}

[OrkhanAlikhanov]

Thanks for the quick response. Actually #7603 made the bug apparent. Before it, the filename had _n.pages now it is [_]n.pages making it even longer and getting truncated. Thanks for the temporary solution.

I still wonder if that much nestedness is a bug or a feature. The url contains dashboards/[_]dashboardId/items/_itemId/details.pages/dashboards/[_]dashboardId/items/... but the if you look at the file tree, the file is dashboards/_dashboardId/items/details.vue, why does nuxt nest dashboards folder inside details.pages folder? How should we interpret that for the easy debugging in production?

[pi0]

@OrkhanAlikhanov Indeed it is not nice a file name when concatenation happens. Using [name] was meant to make tracing chunks easier but we may need a way to simplify it for this case.

[gkatsanos]

I digged in the documention but dont see what the optimal setting for source mapping would be. I'm attaching a debugger to 9229 but I don't get any breakpoints to bind in neither VS debugger nor Chrome dev tools Node inspector ..