Sapper: `dev` flag used by Rollup/webpack configs seems reversed

[jarrodldavis]

It appears that source maps are not enabled for sapper dev but are enabled for sapper build. I'm using the [sapper/svelte v3 rollup] template, and the issue appears to be at the call sites of create_compilers in the CLI command implementations.

Here's some relevant code from some GitHub spelunking:

sapper dev:

https://github.com/sveltejs/sapper/blob/411e2594af6f46ed73c45c1f0db0746adf20bdb5/src/api/dev.ts#L7

https://github.com/sveltejs/sapper/blob/411e2594af6f46ed73c45c1f0db0746adf20bdb5/src/api/dev.ts#L220

sapper build:

https://github.com/sveltejs/sapper/blob/e0de230e1391ec1b4a404faea57fd2cc8bbf9812/src/api/build.ts#L4

https://github.com/sveltejs/sapper/blob/e0de230e1391ec1b4a404faea57fd2cc8bbf9812/src/api/build.ts#L85

create_compilers:

https://github.com/sveltejs/sapper/blob/411e2594af6f46ed73c45c1f0db0746adf20bdb5/src/core/create_compilers/index.ts#L4

https://github.com/sveltejs/sapper/blob/411e2594af6f46ed73c45c1f0db0746adf20bdb5/src/core/create_compilers/index.ts#L14-L23

env.ts:

https://github.com/sveltejs/sapper/blob/411e2594af6f46ed73c45c1f0db0746adf20bdb5/src/config/env.ts#L1-L7

Rollup Config (sapper/config/rollup.js):

https://github.com/sveltejs/sapper/blob/411e2594af6f46ed73c45c1f0db0746adf20bdb5/src/config/rollup.ts#L1

https://github.com/sveltejs/sapper/blob/411e2594af6f46ed73c45c1f0db0746adf20bdb5/src/config/rollup.ts#L20

https://github.com/sveltejs/sapper/blob/411e2594af6f46ed73c45c1f0db0746adf20bdb5/src/config/rollup.ts#L36

Should I go ahead and submit a pull request to reverse the values passed into create_compilers, or is there something I'm not understanding?

[thgh]

JS client sourcemaps seem to be useful:

Dev js without sourcemap (current)

chunk.d6bddd73.js:71 Uncaught (in promise) Error: client js error
    at onMount (chunk.d6bddd73.js:71)
    at run (chunk.666eb2d2.js:15)
    at Array.map (<anonymous>)
    at add_render_callback (chunk.666eb2d2.js:260)
    at flush (chunk.666eb2d2.js:191)
    at init (chunk.666eb2d2.js:354)
    at new App (client.d3c9d90e.js:851)
    at render (client.d3c9d90e.js:1182)

Dev js with sourcemap

about.svelte:13 Uncaught (in promise) Error: client js error
    at onMount (about.svelte:13)
    at run (internal.mjs:21)
    at Array.map (<anonymous>)
    at add_render_callback (internal.mjs:1290)
    at flush (internal.mjs:936)
    at init (internal.mjs:1384)
    at new App (App.svelte:15)
    at render (app.mjs:195)

What tool can read server.js.map?

CSS sourcemaps are generated in both build & dev. And never working.

• In build, the style tags don't have a link to the sourcemap. (intentionally?)
• In dev, https://github.com/sveltejs/sapper/issues/421

[jarrodldavis]

I actually found this issue because I was wondering why the server.js sourcemap wasn't present in dev. VS Code's node.js debugger can use source maps so that breakpoints work e.g. in server routes.

[Seb35]

I also remarked this. I have no opinion about build mode (it could be argumented that it could be useful even in prod) but it should be enabled in dev mode. See also #537 about CSS sourcemaps.

I push two distinct PRs: one in dev, one in build.

[Seb35]

Thinking about this, I can see the initial reasoning:

• in dev mode, JS source files are not minified, hence sourcemaps are useless,
• in build mode, JS source files are minified, hence sourcemaps are useful.

Possibly this issue is wontfix, but in this case the variables names should be changed to improve readability and/or comments could be added.

[jarrodldavis]

As I mentioned earlier, source maps are still useful in development when debugging server routes:

I actually found this issue because I was wondering why the server.js sourcemap wasn't present in dev. VS Code's node.js debugger can use source maps so that breakpoints work e.g. in server routes.

Additionally, source maps also map (as their name imply) back to the original source file; since both server- and client-side code is transformed (by Svelte) and bundled (by Rollup) even in development, it is useful to see the original per-component/per-route source, especially when setting breakpoints.