Ember-cli: Getting ember-cli to work on Windows Subsystem for Linux

[kayakyakr]

Testing out the new Bash on Windows setup with the latest insider preview (14942). I figure this would be a good place for the other crazies like me to list issues and research workarounds.

First issue is with os.networkInterfaces, which is not supported. That prevents ember from installing until https://github.com/indexzero/node-portfinder/pull/41 is applied. The issue behind that is listed here: https://github.com/Microsoft/BashOnWindows/issues/468

The next blocker I'm at a loss for. Running ember s -lr false I get

Serving on http://localhost:4200/
{ Error: socket hang up
    at TLSSocket.onHangUp (_tls_wrap.js:1092:19)
    at TLSSocket.g (events.js:291:16)
    at emitNone (events.js:91:20)
    at TLSSocket.emit (events.js:185:7)
    at endReadableNT (_stream_readable.js:974:12)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    at process._tickCallback (internal/process/next_tick.js:98:9) code: 'ECONNRESET' }
util.js:1032
  var errname = uv.errname(err);
                   ^

Error: err >= 0
    at Error (native)
    at Object.exports._errnoException (util.js:1032:20)
    at exports._exceptionWithHostPort (util.js:1059:20)
    at PipeConnectWrap.afterConnect [as oncomplete] (net.js:1080:14)

No idea what those errors mean or even which sources to find them.

---

Output from ember version --verbose && npm --version:

ember-cli: 2.8.0
http_parser: 2.7.0
node: 6.7.0
v8: 5.1.281.83
uv: 1.9.1
zlib: 1.2.8
ares: 1.10.1-DEV
icu: 57.1
modules: 48
openssl: 1.0.2j
os: linux x64
3.10.3

Note: ember-cli-rails _mostly_ works on WSL because Rails's networking stuff seems less interested in the OS.

[stefanpenner]

TLSSocket seems strange, are you running \w SSL certs?

@wycats you run in this environment, last I checked \w the watcher fixes you where successful.

@eriktrom got any cycles re: the portfinder fun?

[stefanpenner]

cc @felixrieseberg in-case you are interested

[nathanhammond]

@kayakyakr

1. Are you using a /etc/hosts based adblocker?
2. Can you turn analytics off?

That may get you past this error. (This is similar to a typical error that recently started showing up and I'm pattern matching.)

[kayakyakr]

@nathanhammond you nailed the TLS issue. It was due to analytics.

Still blocked and this does not provide much information as to what's going on:

Serving on http://localhost:4200/
util.js:1032
  var errname = uv.errname(err);
                   ^

Error: err >= 0
    at Error (native)
    at Object.exports._errnoException (util.js:1032:20)
    at exports._exceptionWithHostPort (util.js:1059:20)
    at PipeConnectWrap.afterConnect [as oncomplete] (net.js:1080:14)

[eriktrom]

That line of code is deep in nodejs itself, fwiw

[stefanpenner]

@eriktrom ah...

[eriktrom]

For context, windows 10 + portfinder do not currently get along. Windows 10 can run node in 2 contexts, both which break portfinder for their own reasons.

1. Bug when run w/out bash shell: https://github.com/indexzero/node-portfinder/issues/39
2. Bug when being run w/ bash shell: this issue

I believe I have a full solution to this in mind. Thanks @kayakyakr for finding this bug in the bash shell provided by windows. U saved me tons of time + head scratching that may have occurred.

Will provide a full solution and link back soon

[eriktrom]

I'll cut a release with this merge in a few hours if no one sees any issues:

https://github.com/indexzero/node-portfinder/pull/42

[eriktrom]

[email protected] has been published to npm.

There should be no breaking changes but as always no news will be good news :)

[stefanpenner]

There should be no breaking changes but as always no news will be good news :)

nice, good work. Thank you sir!

Closing for now, will reopen if the above fix did not address (or something else related ends up being funky)

[kayakyakr]

@stefanpenner the portfinder issues were not the breaking problem with this bug. It was a side issue that I had opened in portfinder's branch and made mention of a workaround here to see if anyone else was working in this environment.

[eriktrom]

@kayakyakr - can you re-iterate on the breaking problem? Sorry must have missed something? Does booting the express server still cause u issues?

[eriktrom]

ember s -lr false gives u ECONNRESET, is that the case?

[kayakyakr]

Sorry, @eriktrom, you'll have to give me a few hours before I can test again to confirm. I'm back in Linux, will have to reboot into windows.

[eriktrom]

LOL no worries - put everything u find in a gist if it gets long - i finally got windows running with decent perf so don't mind verifying

[nathanhammond]

Reopening for tracking status, @kayakyakr keep us up-to-date. Will close after one week without additional updates. 😄

[eriktrom]

@kayakyakr - fyi - the hack from YARN was reverted w/ windows native shell support - I will merge ur original fix(the same fix in YARN) back in b/c that should still work. However, if there are errors that arise after that(as u mention there we're) lets take a look at the whole problem before solving the last error. Let me know what u find.

[eriktrom]

https://gist.github.com/eriktrom/532ad837acfd6f03b4b4e819ed9b0fb2

[kayakyakr]

Hey guys, finally got back to looking at this again. WSL has added network system calls, which is good. Connecting to Watchman is a little busted, but Nodewatcher does not crash.

But, the good news ends there. Using strace, I have found why it builds the first time but not the second: it seems that something odd is going on with the build.lock file that is being generated. Here are the relevant syscalls:

[pid  9468] stat("/home/tmp/build.lock", 0x7ffffa50f700) = -1 ENOENT (No such file or directory)
[pid  9468] open("/home/tmp/build.lock", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 12
...
[pid  9468] stat("/home/tmp/build.lock", {st_mode=S_IFREG|0777, st_size=0, ...}) = 0
[pid  9468] unlink("/home/tmp/build.lock" ) = 0
...
[pid  9468] stat("/home/tmp/build.lock", 0x7ffffa50f8e0) = -1 ENOENT (No such file or directory)
[pid  9468] open("/home/tmp/build.lock", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = -1 ENOENT (No such file or directory)

build.lock is certainly there, but it's got a very odd permission set. Windows doesn't know what to do with it, it can't be deleted in other bash terminals, but it is removed as soon as the ember build process is killed. The syscall, as you can see, gets "no such file". Will be creating an issue in WSL related to this.

A secondary issue has to do with watchman and I'm trying to isolate the error for the WSL guys. I've been combing through the ember-cli codebase and I cannot find where or how that is being called.

[kayakyakr]

The watchman sock issue that I am trying to isolate: https://github.com/Microsoft/BashOnWindows/issues/1354

The build.lock issue: https://github.com/Microsoft/BashOnWindows/issues/1357

[eriktrom]

@kayakyakr - thanks for following up - u seem to have a knack for finding the missing parts of bash on windows

just curious - did u ever encounter Error: EISDIR: illegal operation on a directory, read or similar? I got that one, not sure why.

at any rate, keep at it, the larger community is likely to benefit as a whole b/c of your digging :)

[kayakyakr]

Breaking things is fun.

I haven't gotten an invalid operation on a directory, but there are lots of oddities going on with how it handles files. The open/unlink/open issue for example is an issue with DriveFS (as opposed to VolFS).

What sort of directory is your project living in? How are you attempting to modify that directory? You should not access VolFS (your ubuntu home) outside of bash itself, otherwise you risk corrupting things in ways linux does not know how to handle.

[eriktrom]

What sort of directory is your project living in?

I'd be lying if I said I really knew - tl;dr - From cmd.exe I run bash which logs me in as root. Then I run su - user to use the user user that came with the install of windows I got from MS Developer Center(or whatever its called). From the bash cli, I create the project within the user home folder (I may have made a subfolder, but that shouldn't matter. I was running all this under Parallels, not native. IIRC your re-booting into windows native, perhaps this changes something too.

The interesting thing about my error is it looks like its calling read on a directory, which of course is invalid - for some reason it thinks the directory is a file, not sure why.

You should not access VolFS (your ubuntu home) outside of bash itself

I read this as well and was sure not to touch it outside of bash.

Doubt my feedback helps ATM, but someone else may come across the same issue, at which case, we'd have two instances of such 'oddity', so leaving this here in case/when that does come along.

Cheerio

(NOTE: this is all from memory, almost a month ago, take with grain of salt)

[kayakyakr]

That sounds like a different issue. If you can boil that down to a simple set of steps, I can test it out on my box or you could report it on the bash issues page to see if anything comes up. running everything under strace is super useful for seeing what it's calling before it's crashing.

[eriktrom]

I left the steps in this gist, which includes the full stack trace. https://gist.github.com/eriktrom/532ad837acfd6f03b4b4e819ed9b0fb2 No need to test unless u have time.

Thanks for the strace tip, will hold onto that one.

If I have time (which may not be for a bit) - I will try booting into parallels and giving it another whirl - the gist is old and I'm sure the WSL has been updated a lot since I wrote it.

thanks for the feedback :)

[rtm]

On a brand new project (ember new), on a brand new installation, I get the following:

Build failed.
The Broccoli Plugin: [ConfigReplace] failed with:
Error: EISDIR: illegal operation on a directory, read
    at Object.fs.readSync (fs.js:655:19)
    at FSMonitor._measure (/home/rtm/repos/ui-7/node_modules/heimdalljs-fs-monitor/index.js:66:21)
    at Object.readSync (/home/rtm/repos/ui-7/node_modules/heimdalljs-fs-monitor/index.js:82:30)
    at tryReadSync (fs.js:456:20)
    at Object.fs.readFileSync (fs.js:493:19)
    at ConfigReplace.getConfig (/home/rtm/repos/ui-7/node_modules/broccoli-config-replace/index.js:122:21)
    at ConfigReplace.build (/home/rtm/repos/ui-7/node_modules/broccoli-config-replace/index.js:27:21)
    at /home/rtm/repos/ui-7/node_modules/broccoli-plugin/read_compat.js:61:34
    at tryCatch (/home/rtm/repos/ui-7/node_modules/rsvp/dist/rsvp.js:538:12)
    at invokeCallback (/home/rtm/repos/ui-7/node_modules/rsvp/dist/rsvp.js:553:13)

The broccoli plugin was instantiated at:
    at ConfigReplace.Plugin (/home/rtm/repos/ui-7/node_modules/broccoli-plugin/index.js:7:31)
    at new ConfigReplace (/home/rtm/repos/ui-7/node_modules/broccoli-config-replace/index.js:13:10)
    at EmberApp.index (/home/rtm/repos/ui-7/node_modules/ember-cli/lib/broccoli/ember-app.js:654:10)
    at EmberApp.toArray (/home/rtm/repos/ui-7/node_modules/ember-cli/lib/broccoli/ember-app.js:1639:10)
    at EmberApp.toTree (/home/rtm/repos/ui-7/node_modules/ember-cli/lib/broccoli/ember-app.js:1662:30)
    at module.exports (/home/rtm/repos/ui-7/ember-cli-build.js:23:14)
    at Class.setupBroccoliBuilder (/home/rtm/repos/ui-7/node_modules/ember-cli/lib/models/builder.js:70:19)
    at Class.init (/home/rtm/repos/ui-7/node_modules/ember-cli/lib/models/builder.js:50:10)
    at Class.superWrapper [as init] (/home/rtm/repos/ui-7/node_modules/core-object/lib/assign-properties.js:32:18)
    at Class (/home/rtm/repos/ui-7/node_modules/core-object/core-object.js:32:33)

[kayakyakr]

@rtm try using strace to see if you can get the exact order of calls and directories that it was trying to access

[jonnii]

I have got this to work. What version of windows are you on? It only recently started working for me.

[stefanpenner]

@hjdivad something seems funky, the monitor should not be enabled by default. this seems unrelated, but we addressed by https://github.com/ember-cli/ember-cli/pull/6452

[stefanpenner]

@rtm lets see if we can debug this:

1. can you open: /home/rtm/repos/ui-7/node_modules/broccoli-config-replace/index.js
2. and at the bottom of the file paste:

ConfigReplace.prototype.getConfigPath = function() {
  console.log('[share this in the issue] getConfigPath', this.inputPaths, this.options.configPath);
  return path.join(this.inputPaths[1], this.options.configPath);
};

Our guess is that should produce a path to a directory, can you tell us what is at that location on disk.

[ylilarry]

same problem as @rtm
ember b

WARNING: Node v7.0.0 is not tested against Ember CLI on your platform. We recommend that you use the most-recent "Active LTS" version of Node.js.

Just getting started with Ember? Please visit http://localhost:4200/ember-getting-started to get going

Livereload server on http://localhost:49152
Serving on http://localhost:4200/
[share this in the issue] getConfigPath [ '/home/ylilarry/test/testyou/tmp/config_replace-input_base_path-WsW0h5uO.tmp/0',
  '/home/ylilarry/test/testyou/tmp/config_replace-input_base_path-WsW0h5uO.tmp/1' ] testyou/config/environments/development.json
The Broccoli Plugin: [ConfigReplace] failed with:
Error: EISDIR: illegal operation on a directory, read
    at Object.fs.readSync (fs.js:655:19)
    at FSMonitor._measure (/home/ylilarry/test/testyou/node_modules/heimdalljs-fs-monitor/index.js:66:21)
    at Object.readSync (/home/ylilarry/test/testyou/node_modules/heimdalljs-fs-monitor/index.js:82:30)
    at tryReadSync (fs.js:456:20)
    at Object.fs.readFileSync (fs.js:493:19)
    at ConfigReplace.getConfig (/home/ylilarry/test/testyou/node_modules/broccoli-config-replace/index.js:123:21)
    at ConfigReplace.build (/home/ylilarry/test/testyou/node_modules/broccoli-config-replace/index.js:27:21)
    at /home/ylilarry/test/testyou/node_modules/broccoli-plugin/read_compat.js:61:34
    at tryCatch (/home/ylilarry/test/testyou/node_modules/rsvp/dist/rsvp.js:538:12)
    at invokeCallback (/home/ylilarry/test/testyou/node_modules/rsvp/dist/rsvp.js:553:13)

The broccoli plugin was instantiated at:
    at ConfigReplace.Plugin (/home/ylilarry/test/testyou/node_modules/broccoli-plugin/index.js:7:31)
    at new ConfigReplace (/home/ylilarry/test/testyou/node_modules/broccoli-config-replace/index.js:13:10)
    at EmberApp.index (/home/ylilarry/test/testyou/node_modules/ember-cli/lib/broccoli/ember-app.js:653:10)
    at EmberApp.toArray (/home/ylilarry/test/testyou/node_modules/ember-cli/lib/broccoli/ember-app.js:1645:10)
    at EmberApp.toTree (/home/ylilarry/test/testyou/node_modules/ember-cli/lib/broccoli/ember-app.js:1668:30)
    at module.exports (/home/ylilarry/test/testyou/ember-cli-build.js:23:14)
    at Class.setupBroccoliBuilder (/home/ylilarry/test/testyou/node_modules/ember-cli/lib/models/builder.js:70:19)
    at Class.init (/home/ylilarry/test/testyou/node_modules/ember-cli/lib/models/builder.js:50:10)
    at Class.superWrapper [as init] (/home/ylilarry/test/testyou/node_modules/core-object/lib/assign-properties.js:32:18)
    at Class (/home/ylilarry/test/testyou/node_modules/core-object/core-object.js:32:33)

[hjdivad]

Our guess is that should produce a path to a directory, can you tell us what is at that location on disk.

@YLiLarry what's at /home/ylilarry/test/testyou/tmp/config_replace-input_base_path-P4CPnXUc.tmp/1/testyou/config/environments/development.json? Presumably this is a dir; if so, is there anything there?

Also, what is testyou/config/environments/development.json? (file, app, symlink, anything weird)?

[ylilarry]

humm /home/ylilarry/test/testyou/tmp/config_replace-input_base_path-{randomstrings}/ is an empty directory after I run ember build.
I'm using Bash on Ubuntu on Windows

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.5 LTS
Release:        14.04
Codename:       trusty 

```bash
$ ember --version
WARNING: Node v7.0.0 is not tested against Ember CLI on your platform. We recommend that you use the most-recent "Active LTS" version of Node.js.
ember-cli: 2.10.0-beta.2
node: 7.0.0
os: linux x64

```bash
$ pwd
/home/ylilarry/test/testyou/tmp
$ ls */*
funnel-output_path-1FQcGnez.tmp/index.html

config_loader-input_base_path-LZjHct5w.tmp/0:
environment.js

funnel-input_base_path-tdA9urws.tmp/0:
app.js  components  controllers  helpers  index.html  models  resolver.js  router.js  routes  styles  templates
$ ls
broccoli_merge_trees-cache_path-R8MLIjPp.tmp       config_replace-cache_path-ehBMPpY4.tmp       funnel-input_base_path-tdA9urws.tmp
broccoli_merge_trees-input_base_path-W3v7WbFS.tmp  config_replace-input_base_path-xlKns6oz.tmp  funnel-input_base_path-ZHGjpVLJ.tmp
broccoli_merge_trees-output_path-IoeQ3oru.tmp      config_replace-output_path-bNbgDJgZ.tmp      funnel-output_path-1FQcGnez.tmp
config_loader-cache_path-pccJD3Ra.tmp              funnel-cache_path-LbJm7o1e.tmp               funnel-output_path-jep38SYU.tmp
config_loader-input_base_path-LZjHct5w.tmp

$ pwd
/home/ylilarry/test/testyou/config
$ ls
environment.js

This is a new project initialized with ember new.

[ylilarry]

@jonnii are you on windows Bash on Ubuntu 16.04?

[stefanpenner]

config_loader-input_base_path-LZjHct5w.tmp/0:
environment.js

it would be nice to see the contents of these files as well.

---

I'll try to get an environment \w bash on windows working. So I don't need to bother you all with our attempts are debugging via github comment.

[ylilarry]

tmp/config_loader-input_base_path-LZjHct5w.tmp/0/environment.js is just a copy ofconfig/environment.js

[stefanpenner]

@YLiLarry thanks.

---

Just started upgrading the old windows Gaming rig. Try to get my own ^^ setup, should make debugging easier.

[jonnii]

@YLiLarry I'm on 14.04.5 which I believe is the default.

[eriktrom]

@jonnii

you mention:

I have got this to work. What version of windows are you on? It only recently started working for me.

anything else u can tell us about ur env would help a bunch. it seems ur the only person that does have this working. what version of windows 10 are u using? what permissions does ur bash user have? are you booting natively or inside a VM?

thanks a bunch, looks like a lot of folks would love to hear what you've got running, and how :)

[eriktrom]

(context)

from man pages, open(2)

One must check for two different error codes, EISDIR and ENOENT, when
trying to determine whether the kernel supports O_TMPFILE functionality.

if u got it to work, it seems you've got O_TMPFILE functionality. The mode + umask is possibly the issue.

when u login, anything special regarding your user going on? Or its group?

more context fun:

The mode argument specifies the file mode bits be applied when
              a new file is created.  This argument must be supplied when
              O_CREAT or O_TMPFILE is specified in flags; if neither O_CREAT
              nor O_TMPFILE is specified, then mode is ignored.  The
              effective mode is modified by the process's umask in the usual
              way: in the absence of a default ACL, the mode of the created
              file is (mode & ~umask).  Note that this mode applies only to
              future accesses of the newly created file; the open() call
              that creates a read-only file may well return a read/write
              file descriptor.

thanks again if u can share here

[jonnii]

@eriktrom i'm on the latest fast ring of windows, the first problem was the os.networkInterfaces one (https://github.com/nodejs/node/issues/7150) which is now solved. From bash for windows I can now create and start a new ember application and browse to it from the browser. I've noticed that performance when building the application from the file system within bash for windows is good, but doing anything in /mnt/c is pretty slow (but not terrible). I think this may have to do with how symlinks are handled...

[eriktrom]

@jonnii - awesome thanks for the feedback

i'm on the latest fast ring of windows
[im] building the application from the file system within bash for windows
but doing anything in /mnt/c is pretty slow

hmm......

[kayakyakr]

Hey guys:

1. You have to be on the fast ring to get this to work. 14965 or 14971 are the two builds that have the most (not all) of what is needed.
2. You should upgrade your ubuntu version to 16.04. The older installs came with 14.04, but they bumped the version recently. I dunno if this would help anything, but it's a good thing to do.
3. Temp files under /mnt/c do not work. Temp files under /home/user do. There's an issue tracking this: https://github.com/Microsoft/BashOnWindows/issues/1357. Please do feel free to add your support for getting that fixed faster.
4. But you cannot access /home/user from windows itself. It's hidden away because accessing those files via windows really screws with the expected linux flags. This isn't a problem if you're a terminal developer
5. Performance on VolFs (/home/user) is pretty good while performance on DriveFs is somewhat lacking. It's not the symlink, it's just that DriveFS hasn't been optimized at all. I think their primary focus right now is getting it stable before the big spring update (which is shaping up to be a mini service pack in size) before they work on trying to make it fast
6. I think there's an issue with watchman and the way broccoli connects to the socket. This is the issue tracking that: https://github.com/Microsoft/BashOnWindows/issues/1354. Use node watcher for now.

[jonnii]

FWIW the only thing I had to do was:

Workaround (which will disable IPv6 support on your machine): Run a cmd as Administrator and run:
netsh interface teredo set state disabled
Afterwards stuff like ip addr show works again

[stefanpenner]

@rtm @YLiLarry et. al I believe I have discovered the root cause. It appears WSL has a bug (or FS quirk) related to symlinks of directories.

Specifically, the following will pass on OSX & actual Ubuntu, but fail on WSL. Likely an issue \w the file system.

fs.mkdirSync('out/foo');
fs.writeFileSync('out/foo/bar.txt', 'hi');

fs.symlinkSync(fs.realpathSync('out/foo/'), 'out/bar');
fs.symlinkSync(fs.realpathSync('out/bar/') + '/', 'out/baz'); // the trailing slash here, causes the above issue.

console.log('out/foo/bar.txt', fs.readFileSync('out/foo/bar.txt', 'UTF8'));
console.log('out/bar/bar.txt', fs.readFileSync('out/bar/bar.txt', 'UTF8'));
console.log('out/baz/bar.txt', fs.readFileSync('out/baz/bar.txt', 'UTF8')); // <-- throws  EISDIR

runnable example: https://github.com/stefanpenner/random/blob/master/strange-symlink-issue/index.js

---

Work around for broccolijs/node-symlink-or-copy

Potentially related WSL issues:

• double '//' causing issues https://github.com/Microsoft/BashOnWindows/issues/1147 (fix apparently inbound)
• https://github.com/Microsoft/BashOnWindows/issues/1421 (just opened, as it appears to be untracked currently)

[stefanpenner]

With my above workaround, and either --watcher=polling or master of ember-cli (which has improved watcher detection). An ember builds + rebuilds on the linux partition of WSL.

There does appear to be an issue, causing extra work (that linux/osx version don't do) to be done during a rebuild, resulting in less then expected performance. I'm investigating that now. Can't seem to replicate this again, maybe something was sideways with my symlinking.

[stefanpenner]

https://github.com/broccolijs/node-symlink-or-copy/pull/29 released as [email protected] now it appears ember-cli#master works on latest WSL without issue.

For some it may require disabling the watcher --watcher=polling although an upcoming release of ember-cli better detects these cases, and WSL apparently also addressed the issue on there end.

If any more issues arise, please make sure you are on the latest WSL, and cli. If the problems persist, please feel free to open an issue.

[pjcarly]

I've managed to get ember running in WSL, the only thing i'm noticing tho is that (re)builds are pretty slow.

I'm running ember s from my source folder out of my windows home directory in wsl (somewhere in /mnt/c/users...), because at the same time i have my source open in VS Code on windows.

Every time I edit and save a file, i'm looking at 10s rebuild time. On a more than decent machine.
It looks promising but as long as I can't get my rebuilds down to a few seconds its unworkable

[jonnii]

@pjcarly the performance of WSL mounted drives is a known problem with WSL. Try running ember s from a linux directory and compare the performance, it should be night and day. To be honest there's not much that you can do to improve performance other than wait for improvements.

[kayakyakr]

@jonnii is right about performance of mounted drives. It's not great. Webpack is a bit faster, but is still slow as compared to native. I've tried editing through webdav which was fun, but made my editor painfully slow and quirky. Just gotta wait for it to get better or the windows team finds a way to mount VolFS in windows proper (both are on their list).

Something that might help in the meantime: if you're running windows defender, make sure you exclude your code directory and add node as a process exclusion. This can speed stuff up a bunch.

[rtm]

You can use an editor that let's you telnet into the WSL box (I use
Putty/Emacs) and it works just great.

You could try installing an XWindows system (I have used VcXsrv) and
running VSCode in Linux, but I haven't tried that.

[pjcarly]

cheers, thanks for the tips. I'll try it out, on a not mounted drive.

Hopefully there'll be improvements coming sooner rather than later, really hoping to make my new winbox as productive as my old macbook

[devinrhode2]

@pjcarly were you able to run VSCode inside linux?

I'm due for a new machine, and am wondering which components (RAM/CPU/SSD) are most important for optimizing ember-cli build+rebuild times. I created a post for this on discuss.emberjs.com.

The Surface Book 2 looks pretty amazing, so I'm VERY curious what kind of build+rebuild times people are actually getting these days with WSL! (Best to consolidate this on the post on discuss.emberjs.com, where I detail a good way to measure build times)

[ballPointPenguin]

@devinrhode2 I have been doing ember development on the Surface Book 2 since the day it was made available. It is a very good machine. However I have not been making as much use of WSL as I expected because a number of things I haven't configured or figured out yet (such as running vs code, docker, postgres, ember integration tests). So I mostly just use non-wsl Windows tools, including git bash, vs code, and docker-compose.

I found that ember build/rebuild is quite slow in native Windows (non-wsl) and so I use docker to speed it up. I hope to write up the details of that soon (maybe today).

[kayakyakr]

@ballPointPenguin I have done all of those things on my book 2. Doesn't take near as long as you'd expect.

It's a little slower, but I recommend using drivefs for your code and symlink that in your WSL home folder. Use docker for postgres and any other services that you can use it for, native windows for things it does well (VSCode, browser), and WSL for builds, servers, and tests.

DriveFS has been getting faster and faster over time.

[pjcarly]

@devinrhode2 Last time I tried ember-cli it was too slow in WSL, I've been dual-booting Ubuntu, and ember-cli + VSCode runs perfectly.

[ballPointPenguin]

I'm putting together my Dockerfiles etc here https://github.com/aliencyborg/ember-cli-docker but it still needs work. Hopefully in the next few days I'll get a chance to test and document my process.

[mcfiredrill]

@ballPointPenguin Is running the build in Docker faster than running it in WSL? 💭