Support Windows

[cinxmo]

Framework does not currently support Windows (though some users have had success with the Windows Subsystem for Linux (WSL)). It should work, and we are working on it.

[mbostock]

I am almost 100% sure that the CLI will not work on win32 as currently implemented. A big issue is that we often use join to create URLs, but only on POSIX systems will that use forward slash as the delimiter. To support win32 we will need to be very careful to distinguish file paths from URL paths, whereas today we often treat the two as the same.

Note that we can continue to use Node’s path module to construct URLs, but we will need to import from node:path/posix instead of node:path as appropriate. See Windows vs. POSIX.

[Fil]

Installing windows on my machine with UTM/qemu, then installing node (and VSCode), I got the dev server to run. As the screenshot shows, there is an issue in Edge on the left, and a problem in the dev server on the right. I could't get anything else to work, because powershell has no “rm” command, so the test and build commands fail immediately. I couldn't endure much more and gave up at that point.

[mootari]

I'd probably focus on making sure that it runs well with WSL?

[mbostock]

Punting until GA future.

[mbostock]

We don’t currently support Windows, but you can use the Windows Subsystem for Linux (WSL):

https://learn.microsoft.com/en-us/windows/wsl/about

[GordonSmith]

Most of Observable uses Linux or Macs, but not Windows. We should test the CLI on a Windows machine before launch

I suspect that for most of your corporate / enterprise customers (the ones who are likely to subscribe) this would not be the case (not a big deal for me personally, but with my day job hat on...)

[mbostock]

@GordonSmith Agree. The “Most of Observable” was referring to Observable, Inc. employees, not users of Observable.

[onnobaudouin]

Installed it via WSL 2m Running AlmaLinux and although the command:

$ npm run dev

Starts and in fact tries to open a browser in my actual windows (10) machine it uses a hostname which doesn't resolve. I.e i see:

 > dev
> observable preview

Observable Framework v1.0.0
↳ http://DESKTOP-R45NOT8:3000/

When i look up in /etc/hosts is see it binds to 127.0.1.1 (bizarre)
Yet the actual Almalinux instance is running and approachable from the windows host on on 172.27.8.29 (and i can ping it)

$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.27.8.29  netmask 255.255.240.0  broadcast 172.27.15.255

Just to test network connectivity i created a simple node server on the same almalinux with this:

const express = require('express')
const app = express()
const port = 3000

app.get('/', (req, res) => {
  res.send('Hello World!')
})

app.listen(port, () => {
  console.log(`Example app listening on port ${port}`)
})

which if i run with node index.js happily starts and i can directly access this on the windows host on 172.27.8.29:3000

So my question is what is observable framework doing under the hood and what is it binding to? Is it starting a docker inside the WSL etc? why is it trying to connect to some weird unknown IP address from

I love D3.js and what looks like an amazing tool, but as the comments above, most data enabled companies will be (Forced? :) to use windows so getting it to work (even in WSL2) would be great.

[mbostock]

It looks like you have the HOSTNAME environment variable set erroneously which is overriding the default of 127.0.0.1. Perhaps we shouldn’t check this environment variable and instead require you to set it explicitly via the --hostname argument.

framework/bin/observable.ts

Line 131 in 3f09fab

default: process.env.HOSTNAME ?? "127.0.0.1"

As to your other comment on the value of supporting Windows, we are working on it but we are only human. 😅

[onnobaudouin]

Thank you

I did try to look for where the server started to see what it did to help further but was looking in the src files .

the way i managed to get around this was in 2 ways:

The idiot way

 $ sudo vi /etc/hosts

127.0.0.1 localhost
# 172.0.1.1 DESKTOP-R45NOT8.        DESKTOP-R45NOT8  <-- this was generated by WSL2 
0.0.0.0   DESKTOP-R45NOT8.        DESKTOP-R45NOT8    

note that putting 127.0.0.1 didn't work either - although it would start it would not allow the windows host to connect to.

Also as AlmaLinux on WSL2 does not use systemd i could not use the normal ways to set the hostname (hostnamectl).

The Build In Way

I then parsed your comments properly and simply changed my package.json

...
"scripts": {
  ...
  "dev": "observable preview --host 127.0.0.1",    
  ...
}
...  

This one is also passed through directly to the host - i.e. browser window opens nicely with the test program whereas --host 0.0.0.0 also worked but requires knowing the full actual IP instead. (using ifconfig)

Happy to be able to start experimenting

As for being human: the elegance of D3 tells me we are somewhat outside that limiting factor

[rinie]

This is a bummer like Steampipe. I am not allowed to install WSL at work and likewise Bash is a cludge.
Is it only about / versus ?

Got the announcement mail and the exitement ends here...

[novotny1akub]

So sad that Observable Framework does not currently support Windows. I was very excited to try it out.

Would it be feasible to get a rough estimate on the potential timeframe for Windows support?

[Fil]

We can't give an estimate but we're as eager as you are to get this to work (ASAP). Thanks!

[gouldingken]

In case anyone else on Windows wants to get up and running quickly and doesn't mind paying for it, you can use Codespaces

Start with a new "blank" codespace template (you don't have to check out a repo with that template). Then run the commands as per the instructions. You can preview your web dashboard while developing via port forwarding.

[mbostock]

Please upvote by clicking the 👍 on the top post. Replying with an “upvote” message triggers notifications that waste people’s time and also does not count as an upvote when sorting issues by popularity. Thank you!

[mythmon]

We have some progress on this now. In #881, I have a prototype of a version of Framework that works for me on Windows. We still have some architectural decisions to make about the approach in that PR, but as a proof-of-concept, it demonstrates what we need to do to support Windows.

For anyone interested in helping to test this, there are some instructions for testing in #881. If you're comfortable with testing in-progress versions of Node programs, please give it a shot. If you have any feedback or problems, please leave a comment on the PR with your experience.

[dleeftink]

Of note here is that I'm able to run the live server running in a VSCode devcontainer (Alpine Linux + Node) on Windows 10, but it seems I'm running into issues of how to build the docker image to watch for file changes in the main folder (the terminal shows the hello websocket message after npm run dev, but does not update on file system changes).

Currently, I get the static preview of each dashboard working fully, but auto-saved edits do not update the preview as they do on my codespace examples. However, a manual refresh of the page does show the updated content.

Is this a conflict between docker permissions and how watch from node:fs interoperate?

[melodykramer]

Hello!

I volunteer for a civics blog in North Carolina and we would like to use this to help our audience understand early voting behavior before our March 5 primary. Looking forward to the Windows version - most of us are on Windows for work/outside of work.

Mel Kramer
Carrboro, NC

[dleeftink]

Of note here is that I'm able to run the live server running in a VSCode devcontainer (Alpine Linux + Node) on Windows 10, but it seems I'm running into issues of how to build the docker image to watch for file changes in the main folder (the terminal shows the hello websocket message after npm run dev, but does not update on file system changes).

Currently, I get the static preview of each dashboard working fully, but auto-saved edits do not update the preview as they do on my codespace examples. However, a manual refresh of the page does show the updated content.

Is this a conflict between docker permissions and how watch from node:fs interoperate?

A quick update on this: you can setup an (Alpine/Debian/Ubuntu) Linux devcontainer in VScode using a configuration file, and instead of opening a folder from the Windows filesystem, you have to store and open folders from the Linux \\wsl.localhost file system (available in file explorer). This allows inotify to watch for file changes, which is necessary for the live updates to propagate to the preview server. The Windows <-> Linux filesystem boundaries are discussed in the context of Docker here: docker/for-win#8479.

I aim to provide a more in-depth tutorial of setting up a .devcontainer on Windows in the coming days.

[novotny1akub]

Since the issue is closed, does it mean Framework should now work on Windows?

[Fil]

If you install it from the main branch on github, yes; but we still need to release it on npm (with release notes, etc.) before it's widely available.

[mbostock]

We will be publishing 1.1.0 to npm early next week.