Generate release source maps

[edusperoni]

Is your feature request related to a problem? Please describe.
Currently, when we build an app with --release no sourcemaps are generated. While sourcemaps should never be in a release build, they are useful for debugging crashes, which look like this in tools like crashlytics:

com.tns.NativeScriptException: Calling js method onCreate failed TypeError: Cannot read property '_context' of null File: "file:///data/data/com.myapp/files/app/vendor.js, line: 1, column: 2310192

Describe the solution you'd like
A way to generate source maps in a directory like project/sourceMaps that can be saved along with the release apk/ipa for when bugs in that release occur.

Describe alternatives you've considered

I've discovered #816 when testing this out. I managed to generate the sourcemaps in a separate directory by setting sourceMapFilename

        output: {
            pathinfo: false,
            path: dist,
            libraryTarget: "commonjs2",
            filename: "[name].js",
            sourceMapFilename: "sourceMap/[name].map",
            globalObject: "global",
        },

and using

devtool: "hidden-source-map",

This generated every sourceMap needed to platforms\android\app\src\main\assets\app\sourceMap\, but it was also bundled in the app. Maybe this could be handled by a after-prepare hook?

My worker's sourcemap was generated to sourceMap/main.map, which seems wrong, and may be an issue when multiple workers are being used.

Additional context

I think we could have a flag similar to --env.report which generates the release source maps to a directory inside the project root.

I'm willing to help implement this feature once we discuss the direction we should be going.

[DimitarTachev]

Hi @edusperoni,

Sorry for the late response and thanks for your UglifyJs source maps contribution! We've merged it and it should be available in nativescript-dev-webpack@next.

Regarding the source maps output path, you are missing that the sourceMapFilename property is a relative path based on the output path. In other words, in order to get it generated in your project dir, you need to configure it like below:
sourceMapFilename: join(relative(dist, __dirname), "sourceMap/[name].map")

We are still wondering about the best way of exposing this through the CLI API. We could automatically generate hidden source maps at project level when you execute tns ... --release --env.sourceMap, we could expose the source maps type and location configurable through additional env flags or we could expose a single env flag for switching to hidden source maps at project level. What do you thing about it?

[edusperoni]

Using sourceMapFilename: join(relative(dist, __dirname), "sourceMap/[name].map") solves that issue, indeed!

We still have the worker problem, but that can be sorted out later.

I find it ambiguous for --env.sourceMap to behave differently in --release. Also, testing the external sourceMaps wouldn't be possible without --release. I think we have basically two options:

1. Create --env.extSourceMap/ --env.externalSourceMap/--env.hiddenSourceMap or something more friendly and, when that is specified, we export the sourceMaps to baseDir/sourceMap (this is the same behavior from --env.report)

2. Allow for --env.sourceMap=path/here (or --env.extSourceMap=path/here, allowing both the default and a customizable one) which would activate hidden-source-map to that directory.

Using external source maps is basically useless for debugging in NS, unless you bundle them with the code, which gives the same effect as the current default (inline), so I don't see any advantage in just enabling hidden source maps.

My thinking behind this is that most developers would rather just have a single flag to enable it, like --env.report, in a way that is easily accessible (sourceMaps dir), so they can just use it in (mostly) production release. For the rest, editing webpack.config.js is trivial.

[DimitarTachev]

Thanks for the feedback!

I've opened a pull request with env.hiddenSourceMap option which can be passed both as boolean and string (path to the source maps folder).

Regarding the issue with your worker names, it seems that it is caused by the provided sourceMapFilename. In the above-mentioned PR, I'm using [file].map instead of [name].map and the worker maps are generated as expected.

[gajus]

I am confused by hiddenSourceMap feature.

The resulting hash does not match the original file.

❯ ll dist
total 2432
drwxr-xr-x   8 gajus  staff     256 Jul 14 20:41 ./
drwxr-xr-x@ 27 gajus  staff     864 Jul 14 20:23 ../
-rw-r--r--   1 gajus  staff      71 Jul 14 20:41 main.229b9a9cafbc8da1699d.css
-rw-r--r--   1 gajus  staff     207 Jul 14 20:41 main.229b9a9cafbc8da1699d.css.map
-rw-r--r--   1 gajus  staff  266181 Jul 14 20:41 main.9f253af8efd23a9c3c7c.js
-rw-r--r--   1 gajus  staff    1910 Jul 14 20:41 main.9f253af8efd23a9c3c7c.js.LICENSE.txt
-rw-r--r--   1 gajus  staff  959981 Jul 14 20:41 main.ab1ddd93c33039746aaa31dcf9112693.map
-rw-r--r--   1 gajus  staff     153 Jul 14 20:41 manifest.jso

I expect main map file to be named main.9f253af8efd23a9c3c7c.map.

[gajus]

Related issue scinos/webpack-plugin-hash-output#21 (comment)