Running code through lsc with --map will cause an error

[msteen]

I really want to be able to use source maps when using LiveScript in NodeJS, but it only seems to work for precompiled files. If I ask it to generate source maps when running LiveScript code on NodeJS, it will fail with the following error:

> lsc --map embedded file.ls

Failed at: file.ls
[SyntaxError: /path/to/file.ls:1
(function (exports, require, module, __filename, __dirname) { [object Object]
                                                                      ^^^^^^
Unexpected identifier]

It seems like a bug, because it fails on [object Object], which is seems like a bad call to toString.

For now I work around it by precompiling the LiveScript code, but I am new to using a transpiler like LiveScript in NodeJS, what is the best practice here? Do you store the generated JS in a separate folder and add this folder to the paths that the require function checks? Or how do you prevent the generated JS files from polluting your source folders?

[heavyk]

last I knew of, node did not out of the box do source map transformations on your stack traces. I just did a search and this may be what you're looking for to solve your problem.

https://github.com/evanw/node-source-map-support

[msteen]

Thanks, but I am already doing that. It indeed is necessary for source maps to work for stack traces. And it does work, if I first compile to a .js file, and then run that file through node. However when I use lsc to run the code with the --map parameter, it won't even get to the point where it could require that module, because it will fail loading the module due to that [object Object] being at the beginning of the generated JavaScript.

[msteen]

I found the bug. If you supply the map parameter the compile function will return an object rather than a string, but when running code directly this check apparently was forgotten.

Should probably have a similar check as is been done a few lines below it.

[msteen]

Fixing that, makes the code run with the map parameter again, but for some reason source-map-support does not work when running the code directly.

[heavyk]

send a PR with the fix then... did you require('source-map-support').install(); before running it in the new context (or putting it at the top of the compiled source)?

I think what's happening is the install function probably will not work with LiveScript.run because it's just a new Function so, I'd have to look at the source-map-support module's install function to see what it's doing -- and you'll need to do the same thing and try running it instead with vm.run-in-this-context. it may be trivial -- not sure.

[heavyk]

wait, new function shouldn't make any difference. I need sleep. I'm not sure where the problem is. I also had a look at the install function and it looks like it's just massaging the text on uncaughtException - so it should be getting your errors..

good luck & good nite :)

[msteen]

I just edited the source code via GitHub. I changed two files, and did not know how to merge them into one through GitHub interface, so I just made two pull requests: #832 (the fix) and #833 (more consistent check).

However this only fixes the bug of crashing due to the incorrect call to toString. It will not fix the source map support. I checked CoffeeScript and they also do not support source maps when running coffee files directly, for what I tested at least.

As far as I know you cannot retrieve the code passed into eval when inspecting a stack trace of an error that happened within eval'ed code. That is why they check for "//# sourceURL=...", and without that, they cannot extract the embedded source map. But if you have to write the code you plan to eval to the file system first, you might just as well require the file directly instead of using eval. But then you might as well just first transpile to JS, which is what I am going to now. A src folder with LiveScript and lib with the generated JavaScript, just like the compiler does.