Vuepress: Generated js files have SyntaxError when enabling source map in webpack config

[jjyyxx]

• [x] I confirm that this is a issue rather than a question.

Bug report

When enabling source map in the configureWebpack option, the generated js files have SyntaxErrors. Comment the devtool: "source-map" line solves the problem.

Version

1.0.0-alpha.40

Steps to reproduce

git clone https://github.com/jjyyxx/vuepress-1367-repro.git
cd vuepress-1367-repro
npm run build

What is expected?

Generate valid code.

What is actually happening?

Uncaught SyntaxError: Unexpected token } happens in app.xxx.js.

Other relevant information

• Your OS: Windows 10 1809
• Node.js version: v11.4.0
• Browser version: Google Chrome v72.0.3626.119
• Is this a global or local install? local
• Which package manager did you use for the install? npm
• Does this issue occur when all plugins are disabled? yes

[sinchang]

it's working on my local macOS dev workspace.

[jjyyxx]

@sinchang Thanks for your test! Could you upload your syntactically correct app.[hash].js file (rename to a txt)?

I have tested under Windows 10 and Ubuntu. Evaluating the app.[hash].js under both platforms led to

Uncaught SyntaxError: Unexpected token }

[sinchang]

@jjyyxx https://gist.github.com/sinchang/50902d8f0ce37f4cf5a4353ff7e87fc2

[jjyyxx]

@sinchang Thanks for your quick reply. But when I try to evaluate your gist in the browser, the error

Uncaught SyntaxError: Unexpected token }

persists. Are you sure your gist could run without syntactical problems under macOS?

[Shigma]

@sinchang It seems that your gist begins with

//# sourceMappingURL=styles.bf997139.js.map!function(t){
//                                         ^ there should be a newline

This can explain the problem @jjyyxx encountered.

[sinchang]

@jjyyxx sorry, my fault. build success but open in the browser has the same problem

[sinchang]

@jjyyxx it's working when update config to

module.exports = {
  configureWebpack: () => {
    devtool: 'source-map'
  }
}

[jjyyxx]

@sinchang You misused lambda.

In

() => {
    devtool: 'source-map'
    // "devtool:" is an unused label
    // 'source-map' is an unused string literal expression
}

It is pretty valid javascript but may not be what you what to achieve.
The correct way is

() => ({
  devtool: 'source-map'
})

which returns an object and fails as exprected.

[jjyyxx]

I found that the function workaroundEmptyStyleChunk caused this problem.
https://github.com/vuejs/vuepress/blob/1850be7f343e54575c64d82c4f0cedc25a9aa91c/packages/%40vuepress/core/lib/build.js#L174-L190

The hack was introduced to address this issue. This snippet prepends styleChunkContent to appChunkContent and writes it back to app.[hash].js. When building chunks without sourcemap, each chunk ends with a semicolon (always?). So the prepending operation generates valid code.

BUT, if sourcemap is configured to be generated, webpack will append a comment line to the end of each js chunk, which breaks the precondition of each chunk ends with a semicolon, leading to invalid code after prepending.

[jjyyxx]

A simple workaround is inserting a line break when concatenating styleChunkContent and appChunkContent. While the SyntaxError will be resolved, another problem remains that the sourcemap for app.[hash].js will be invalidated because the whole chunk deviates from the original location by around 100 characters.

@yyx990803 The hack was introduced around a year ago, but its impact to sourcemap might not get considered yet. Could you offer some hints to solve this problem gracefully?

[Shigma]

Maybe we can make a simple judgment before using this workaround:

if (!config.devTool) await workaroundEmptyStyleChunk()

Since we usually don't need a sourcemap in a real production phase, I think this approach is understandable.

[yyx990803]

@jjyyxx I think a more fundamental fix would be having the empty chunk issue fixed in webpack itself... thus getting rid of this hack altogether...

[jjyyxx]

@Shigma I tested the patch and it worked as expected. Is it possible to be added into the next version?

I don't think it's a breaking change. And it only introduces an if statement which can be removed together when the upstream issue fixed.

[Shigma]

@jjyyxx contribution welcome! 😆

[jjyyxx]

pr created at #1378