Use inline source maps when transpiling coffee-script

[Ingramz]

Since sourcemaps still refer to .coffee files after build, we shouldn't be deleting those from final output directory. Debugging from devtools with latest builds is practically impossible without them.

cc @as-cii

EDIT -

The approach has changed a bit since the PR was opened. See the comment below.

[Ingramz]

CI has trouble retranspiling source map references to files, so I don't know if compile-cache.js needs to contain the change it currently has or if the Windows specific block should be omitted. Locally both seem work, though.

[XVincentX]

I approve those changes

[damieng]

Every one of our compilers already adds the source map and does the file:// work on Windows. I suspect this entire function can be removed.

[Ingramz]

Verified, yep, it can be removed.

[Ingramz]

There is still trouble with getting devtools to load .coffee files from asar. It will pretty much break as soon as the person building deletes their build directory.

[maxbrunsfeld]

There is still trouble with getting devtools to load .coffee files from asar.

Yeah, to make this work we would probably need to modify Electron to make the dev tools aware of .asar files.

I think that instead, we should just remove the source map URLs from the transpiled files that we ship. Eventually, we will stop using CoffeeScript. Though we may still use Babel to transpile our source files, the output will be pretty easy to read compared to the output of the CoffeeScript compiler.

[maxbrunsfeld]

@Ingramz are you interested in submitting a different PR to simply remove the source maps from the transpiled files that we ship?

I believe we'd need to change these files:
https://github.com/atom/atom/blob/master/script/lib/transpile-babel-paths.js
https://github.com/atom/atom/blob/master/script/lib/transpile-coffee-script-paths.js

As for this PR, in my opinion it is not worth including the un-transpiled version of every file in the app, especially since there would be some complexity in getting them to display correctly in the dev tools.

[damieng]

I'm not keen on losing the source maps entirely as they're pretty essential for debugging in our current Coffeescript world and even with Babel without them setting breakpoints etc. will be wrong.

One compromise might be to only include them in local dev builds and not include them in production/release versions.

[thomasjo]

One compromise might be to only include them in local dev builds and not include them in production/release versions.

I think this is the route we should take, at least until we can find a better solution (which will likely require changes in Electron as @maxbrunsfeld has mentioned).

[maxbrunsfeld]

I'm not keen on losing the source maps entirely as they're pretty essential for debugging in our current Coffeescript world

They already don't work, right? AFAIK, the only time you'd see coffee-script files are when the coffee-script has been compiled dynamically, e.g. non-bundled packages, or Atom's source code when running in dev or test mode.

[damieng]

Some of them do work now but not all it would seem. I need to investigate.

On Thu, Sep 22, 2016, 5:50 PM Max Brunsfeld notifications@github.com
wrote:

I'm not keen on losing the source maps entirely as they're pretty
essential for debugging in our current Coffeescript world

They already don't work, right? AFAIK, the only time you'd see
coffee-script files are when the coffee-script has been compiled
dynamically, e.g. non-bundled packages, or Atom's source code when
running in dev or test mode.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#12713 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAHQp3sYxmeqWeB96FxlqRjGkr2uHphSks5qsrHCgaJpZM4J_rUV
.

[iolsen]

I've found that commenting out the unlink of coffeescript files, one of the changes in this PR, has made debugging e.g. pane.coffee work as expected. What about adding a build arg to leave those in place for when you're building locally for dev/debug purposes? Certainly I agree it makes sense to leave them out of the released installers.

[maxbrunsfeld]

I've found that commenting out the unlink of coffeescript files, one of the changes in this PR, has made debugging e.g. pane.coffee work as expected.

It will pretty much break as soon as the person building deletes their build directory.

👍 I just reproduced both of these behaviors and am understanding this a little better now. So in our new build scripts, coffee-script files are compiled with source maps, but the source map paths point to a temporary location in the out folder of the Atom repository, where the coffee-script files were copied to before being transpiled.

So as long as you keep those temporary files around, the coffee-script files will load correctly in the dev tools. If you remove the temporary files, or run another build (even without installing), the source maps will either stop working or will start pointing to the wrong versions of the files.

We could add a build flag to opt into this behavior, but it's a pretty fragile and hard-to-explain behavior. And seeing as how it would mostly get used during development, it seems like the existing Dev mode is a better solution to this problem.

Thoughts?

[Ingramz]

Conveniently coffee-script 1.11.0 was released two days ago, which adds support for inline source maps, which should solve problems with referencing source files from asar.

[Ingramz]

I tried coffee-script 1.11.0 and inline sourcemaps do seem to work as intended. Made appropriate changes to this PR, requires #12780 to be merged first.

[maxbrunsfeld]

@Ingramz This looks great. It looks like one CompileCache test is failing:

CompileCache
  addPathToCache(filePath, atomHome)
    when the given file is coffee-script
      it compiles the file with coffee-script and caches it
        TypeError: output.replace is not a function
          at Object.exports.compile (/Users/distiller/atom/src/coffee-script.js:44:17)
          at compileFileAtPath (/Users/distiller/atom/src/compile-cache.js:77:31)
          at .<anonymous> (/Users/distiller/atom/spec/compile-cache-spec.coffee:67:24)

Could you take a look at that?

[Ingramz]

@maxbrunsfeld should be good now.

[maxbrunsfeld]

Thanks so much for investigating this @Ingramz!

[Ingramz]

@maxbrunsfeld for this to kick in, I suspect that compile-cache needs to be cleared on CI.

[maxbrunsfeld]

Great point @Ingramz. Done.