sveltekit build step appears to error out on windows

[magorlick]

Description

We had a report from a windows user that npm run build does not seem to work for him.

Assigning this to Brendan Colloran since he has a windows machine.

Couldn't pass beyond "npm run build" · Issue #168 · rilldata/rill-developer

[magorlick]

Brendan Colloran April 25, 2022, 9:37 PM Had a quick call with Hamadri just now, verified that it should be fine to work on the open source code and be logged into web service accounts owned by Rill from my own hardware. Thanks Himadri Singh ! :slight_smile:

I can verify that the Docker container works on Windows+Linux if that’s the direction we’re heading.

Edit

Delete

:thumbsup: 1

Himadri Singh April 25, 2022, 9:15 PM btw, docker should resolve all these multi-os/multi-env issues.

Use docker compose to setup by himadrisingh · Pull Request #166 · rilldata/rill-developer

Edit

Delete

Himadri Singh April 25, 2022, 9:14 PM We should be good with any OS policy we stick too. We don’t have any specific policy for this case.

Edit

Delete

Marissa Gorlick April 25, 2022, 9:12 PM Himadri Singh , could you provide takes here?

Edit

Delete

Marissa Gorlick April 25, 2022, 9:12 PM This project is open source, so we should be able to pull down the repo and examine this bug on any machine. Concerns around related Rill apps. Can he be logged into other services on his personal machine?

Edit

Delete

[bcolloran]

Finally had time to look into this -- building on Windows currently doesn't work because of the bash scripts (and Perl scripts within one of our bash) that we have as build dependencies. This affects both npm install within a cloned repo, but also the new npm install -g @rilldata/rill installation option.

I think the options are: a) just decide that we don't want to prioritize windows b) tell windows users they need to install Windows Subsystem for Linux, and the other deps they'll need (this would be an unrealistically bad option I think -- IMO this is a very very high bar, much worse than docker) c) replace all of the bash scripts with plain node scripts, which hides the cross platform stuff behind a layer of abstraction.

I think option (c) is our best bet. It looks like none of these bash scripts are so involved that replacing them should take too much work.

@hamilton @AdityaHegde any thoughts?