ES6 imports not supported in atom? (Solved?)


I started working through the flight manual to learn about how to build an atom package. I have noticed several things.

1 - The examples given are written in JavaScript es6 (import/export), however the generated package is in CoffeeScript using commonJS (require).
2 - When I try modifying the package to use any es6 (either in CoffeeScript or JavaScript) I get a big fat error when I try to activate my package (see below).
3 - When searching for this issue I get a bunch of hate for CoffeeScript in favor of es6 (which makes no sense as they are completely separate and independent languages I mean CoffeeScript compiles into ES6) and no help whatsoever on why es6 doesn’t work in my package. (note: don’t be hatin’ on CoffeeScript - I LIKE CoffeeScript)

The main question is WHY does import/export not work in my package when everyone else says it should? I’m pushing my broken package up to GitHub here. Any help would be appreciated.

My specs:

Atom: 1.24.0 x64
Electron: 1.6.16
OS: Mac OS X 10.13.3

My error:

Stack Trace

Failed to activate the atom-darklite package

At Unexpected token import

SyntaxError: Unexpected token import
    at Module.get_Module._compile (/Applications/
    at Object.value [as .coffee] (/Applications/
    at Module.load (module.js:488:32)
    at tryModuleLoad (module.js:447:12)
    at Function.Module._load (module.js:439:3)
    at Module.require (/app.asar/static/index.js:47:45)
    at require (internal/module.js:20:19)
    at customRequire (/Applications/<embedded>:96:26)
    at Package.requireMainModule (/Applications/
    at Package.activateNow (/Applications/
    at activationCommandSubscriptions.add.commandRegistry.onWillDispatch.event (/Applications/
    at Function.module.exports.Emitter.simpleDispatch (/Applications/
    at Emitter.module.exports.Emitter.emit (/Applications/
    at CommandRegistry.handleCommandEvent (/Applications/
    at KeymapManager.module.exports.KeymapManager.dispatchCommandEvent (/Applications/
    at KeymapManager.module.exports.KeymapManager.handleKeyboardEvent (/Applications/
    at WindowEventHandler.handleDocumentKeyEvent (/Applications/


     -5:22 atom-darklite:toggle (input.hidden-input)

Non-Core Packages

atom-darklite 0.0.0 
atom-like-brackets-editor 1.2.0 
atom-yarn 0.6.0 
auto-create-files 0.1.0 
autocomplete-glsl 0.2.3 
autocomplete-love 0.4.0 
autocomplete-lua 0.9.0 
autocomplete-module-import 0.3.0 
autocomplete-modules 1.11.0 
black-ui 0.3.5 
block-select 1.0.0 
bottom-dock 0.4.4 
bracket-padder 0.4.2 
build-tools 4.5.12 
busy-signal 1.4.3 
case-switch 2.2.4 
coffee-navigator 0.0.18 
coffee-paste 0.8.0 
coffeescript-check 0.2.0 
editorconfig 2.2.2 
file-icons 2.1.16 
formatter 2.12.4 
grunt-manager 0.1.16 
grunt-snippets 0.1.1 
gulp-manager 0.2.19 
hyperclick 0.1.5 
hyperclick-love 0.6.0 
hyperlink-hyperclick 1.3.4 
indentation-indicator 1.1.0 
intentions 1.1.5 
ir-black-k-syntax 0.2.3 
js-hyperclick 1.13.0 
language-gitignore 0.3.0 
language-glsl 2.0.4 
language-lua 0.9.11 
language-markdown 0.25.1 
linter 2.2.0 
linter-coffeelint 1.3.1 
linter-eslint 8.4.1 
linter-flow-plus 3.1.0 
linter-luacheck 2.0.1 
linter-ui-default 1.6.10 
love-ide 0.17.0 
open-file-in 1.2.3 
package-script-runner 0.2.1 
package-switch 0.5.0 
path-hyperclick 0.3.0 
platformio-ide-terminal 2.8.0 
prettier-atom 0.51.0 
project-manager 3.3.5 
swackets 0.35.0 
symbol-gen 1.3.1 
sync-settings 0.8.3 
todo-manager 0.2.10 

CoffeeScript Roadmap

Note: The things I have tried.

Adding ### @babel ### as the first line as mentioned in another post.

Adding the directive “use babel” to the first line as shown in the flight manual (tried both “use babel” and ‘use babel’).

Nothing seems to work.


I‘m writing my own packages in CoffeeScript, so I couldn‘t answer this. However, you could always run your code through Babel in the postinstall script.


I’m writing my package in CoffeeScript as well - which supports import/export syntax, so why am I having this issue?


According to CoffeeScript documentation:

Note that the CoffeeScript compiler does not resolve modules; writing an import or export statement in CoffeeScript will produce an import or export statement in the resulting output. It is your responsibility attach another transpiler, such as Traceur Compiler, Babel or Rollup, to convert this ES2015 syntax into code that will work in your target runtimes.

I’m guessing Atom doesn’t run the compiled CoffeeScript through a transpiler? This would mean the import is given as is to Node, which doesn’t support ES6 modules (just yet).
The ES6 examples in the flight manual however are run through Babel invoked with the 'use babel'; statement. Perhaps there’s a similar way for CoffeeScript but I don’t know it.

So anyway, either only use require or as @idleberg wrote, you could run your package through Babel manually.
Personally I’d say you might be better of long term by writing your package in ES6 from the start, as Atom is in the process of switching from CoffeeScript to ES6.


This is correct, and there are no plans to do so in the future.


If it is not transpired why does it show es6 in the flight manual. The “use babel” directive doesn’t work (either in CoffeeScript or JavaScript as stated above).


Can you please link to one of the Flight Manual pages using import/export syntax? That will help us get on the same page.


It’s the very first tutorial.

  • Jim Hessin


Thanks for the link. As we are transitioning away from CoffeeScript, we are also changing the Flight Manual to show ES6 examples as well; all code snippets on that page are written in JavaScript, not CoffeeScript. The default language for package-generator to output has also been changed to JavaScript, so make sure you’re running the latest version of Atom.

I don’t know why 'use babel' isn’t working for you in JavaScript as some of Atom’s own packages use Babel features. Perhaps try /** @babel */ instead and see if that works.


I’m very sorry to hear that you are moving away from CoffeeScript. Do you not use the latest version anymore? Has it gotten that bad? I can get `/** @babel / to work but only with that extra star at the beginning. I find that if I use the latest version of coffeescript and transpile ### @babel ### it would work - however atom must not use the latest because that doesn’t work unless I compile it myself. Can I ask why you are moving away from supporting CoffeeScript? It is a much cleaner language and easier to read and it compiles to es6 which is what you are moving toward. It seems like putting the cart before the horse to me.


Does anyone know how I might go about doing this? It might be good to be able to use an up to date coffeescript compiler. I’m working through the flight manual so if it’s there I should hit it soon enough.


Here’s a fairly recent topic about the CoffeeScript -> ES6 conversion if you’re interested. No more Coffee. Decaffeinate the Atom’s Core. Atom without Coffeescript

Atom is currently using CoffeeScript 1.12.7. We will not be upgrading to CoffeeScript 2.x or above and there are no guarantees that we will continue to upgrade to new 1.x versions.


None of this answers the why? I mean why not keep a link to the latest CoffeeScript transpiler for package developers? What does it cost? From what I’ve seen every developer that has given it a chance prefers CoffeeScript to JavaScript - and it compiles to javascript es6 super easily and quickly. I understand maybe wanting to transition your code to javascript for stubborn developers that don’t want to learn something new - but that is easily done with a coffee transpiler - so why not support both?


Please don’t derail this topic into another CoffeeScript vs. ES6 ‘discussion’. There are enough of them on here. Keep it at solving your problems.

You can compile it through an npm script, as simple examples:

  • postinstall, if you want it compiled on the users machine
  • preversion, if you want it compiled before a new release and install with the compiled files ready to use

In either case the main in your package.json will have to be the entry point to the compiled files.


Install hooks are sufficient for package distribution, but it might be annoying to have to take an extra step to transpile the code before reloading Atom when you’re developing. An in-Atom solution to that problem could come in the form of a process-palette command which is called by an atom.workspace.onDidSave() listener in If you just build one file at a time, you shouldn’t notice a difference in speed.


Okay this is what I did and it works well.

  1. I moved my .coffee files into src/
  2. I added the following to package.json
"scripts": {
    "start": "coffee -o lib/ --no-header -cbw src/",
    "prepublish": "coffee -o lib/ --no-header -cb src/"
  "dependencies": {
    "atom": "^1.1.0",
    "coffeescript": "^2.2.1"

Now while developing I simply run yarn start (#yarnfan) and all of my .coffee files are automatically compiled to es6 and placed in the ./lib folder. It seems like this should be unnecessary though as atom was built using this technology.

Yes. I know. I’m not trying to start an argument, but noone has given me a solid reason why updating coffeescript is so difficult for atom. And also if atom is moving to es6 why is the /** @babel */ directive necessary? Shouldn’t the package be transpiled automatically?


My next problem is posted here:

If the solution is lower the security of my github account so I can publish a package I’m not going to be happy :weary: - after this topic discussion though I’m not sure what to expect.


CoffeeScript 2.0 breaks backwards-compatibility. We’ve already had enough trouble with previous minor CoffeeScript upgrades breaking backwards-compatibility that we feel that the effort required to make sure no community packages break is not worth the cost.

We are also moving away from automatic package transpilation, which is why /** @babel */ is required. At this point the only significant thing that Babel does is allow you to use ES6 import/export syntax. Personally, that syntactic sugar is not enough to convince me to add the Babel directive rather than using the CommonJS require syntax.