Windows Support

process.env.PWD is undefned on Windows systems. It’s usually encouraged to use process.env.cmd instead but I’m not sure what the implications are on this specific project.

[JamesCullum]

Thanks everyone for your support - using the fork of @romaric-juniet I was able to get it running. I will leave this open for other users as a guide until it is fixed on the main version.

Steps to take to make it run on Windows

1. Find the path of the doxity you probably already installed via where doxity
2. Visit that folder and delete the doxity files (npm uninstall -g doxity supposedly does the same but didn’t remove it for me)
3. Download the Windows version of solc here and extract the files directly into the same folder from 1 (as it points to %PATH% and allows you to use the solc command inside the script)
4. npm install -g romaric-juniet/doxity to install the fork as global doxity. You should see the doxity files reappear in the folder.
5. Open up the command line and navigate to the dproject directory
6. Run doxity init which now works (original can’t even init)
7. I’ve had to point it directly to the parent contract via doxity build --src "contracts\Contract.sol", as neither wildcards, nor absolute paths worked.
8. It compiles the contract and creates all files in the docs folder. Deploy that folder on your webhost.

Optional Opening the HTML files in your browser won’t work, as the docs folder creates some files only once. Use npm install -g http-server to install a webserver. Navigate to the docs folder with the javascript files on the same level and run http-server - now you can navigate and have all pages render correctly.

[alexpArtos]

I have cloned Doxity in my windows platform, and done some changes to make it run. I’m still new to contributing to public gitHub projects like this. What would be the best way for me to share this work with the community?

At the moment, I am able to produce documentation successfully on Windows. The changes I made fall in these categories:

• use path.join to concatenate paths, instead of using hardcoded ‘/’
• add logic to detect the platform, and run npm.cmd or npm as appropriate (in init.js or publish.js)
• added logic to expand a final ‘*’ wildcard in the path to contracts to all the files below it, since this is not automatically done by the Windows command line
• changed the name of the tarball file downloaded in init.js, to avoid whitespaces, because these were giving me some trouble.

There are 2 more changes that are necessary to make the tool run, but which I don’t personally like:

• I changed my package.json to make the “compile” target work in Windows. I don’t know how to make it work both for windows and *nix simultaneously, so this is a very targeted change. I welcome suggestions on how to make it more general.

• In order to get around the process.env.pwd, I used a maybe hacky solution: I created a new doxity.cmd that I invoke locally and which sets an environment variable called PWD. I have seen people using cwd(). When I started adapting Doxity, I looked it up to see what cwd() does and I found this post: https://stackoverflow.com/questions/31414852/process-env-pwd-vs-process-cwd which put me off using cwd(). Any comments welcome.