porsager / wright

🚀 Work Fast Work Wright
Do What The F*ck You Want To Public License
180 stars 15 forks source link

Wright tries to write to non-existant filepath when starting #24

Closed orbitbot closed 7 years ago

orbitbot commented 7 years ago

On Ubuntu 16.04.2 when configuring a new project and running:

wright dist/index.html -r "m.redraw()"

... wright errors out with the following

16:17:53.378 Error: Error writing session { Error: ENOENT: no such file or directory, open '/var/local/wright/wright.session.json'
    at Error (native)
    at Object.fs.openSync (fs.js:641:18)
    at Object.fs.writeFileSync (fs.js:1347:33)
    at save (/home/patrik/git-repos/nihao/web/node_modules/wright/lib/session.js:46:8)
    at Object.module.exports.set (/home/patrik/git-repos/nihao/web/node_modules/wright/lib/session.js:18:3)
    at utils.request.then.catch (/home/patrik/git-repos/nihao/web/node_modules/wright/lib/chrome/probe.js:18:13)
    at process._tickCallback (internal/process/next_tick.js:109:7)
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: '/var/local/wright/wright.session.json' }

fs.writefile does not create the full path to the file for you (in this case the folder /usr/local/wright/ does not exist from before). Also, on Linux a user process does not have write permissons to the /usr/local/ folder, so for this approach to be possible it would need to escalate to root user privileges. It does not matter if wright has been installed globally or not. I'm not sure on how permanent the folder contents actually need to be, but if they can reasonably be recreated on f.e. device boot, I don't see any particular reason not to use a folder below /tmp/ instead, which can be written to by user processes and exists on both OSX and Linuxes.

porsager commented 7 years ago

Yeah, that doesn't seem well thought out. The settings wright saves are supposed to be persistently saved since a chrome session will be kept for each project being started. Wright also automatically assigns a port for each project that is kept in store. This is beneficial for running multiple projects with wright at the same time and also to make it easier with a project specific url when testing in different browsers / on different machines / sharing a link to the project. I've made it use /home/user/.wright as the appdata dir on linux, but let me know if you have a better suggestion ;)

I've released 0.7.3 which should work on Ubuntu.

orbitbot commented 7 years ago

I was wondering if it might be possible to write to the node_modules folder where the wright executable is running from, rather than something in the home folder. In Node, the __filename environment variable should point to the currently executing file path (not process.cwd() which is where it's launched from). At least in that way it would be tied to the installation instead of leaving cruft around if someone happens to uninstall wright. That wouldn't be as permanent ofc, but I don't have a good understanding of how "permanent" the settings would need to be or what would be lost if you occasionally nuke your node_modules for example.

BrowserSync, devd and the like just open the first available port from their defaults, so I'm not sure how necessary keeping the port number is. You could also task the user to provide the appropriate config as a parameter instead if they care about permanence. Since wright also launches the browser, I don't know if there would be a hugely significant loss of flow if you happen to be working on multiple projects at once in practice. Opinions may vary ;)