Bug: ENOTDIR, not a directory

[baruchiro]

Fixes #170

In the first commit- 4bcdb0d I just tried to avoid multi download. But I think we still have an issue with the executable location (in dev env it downloaded to the node_modules by default, and I think it have an execute permission problem).

In the commit 812be09, I injected the chromePath from the point before we starting to scrape each importer.

But then I thought the backend shouldn't depend on electron, it should just do its work, so it can get an optional download path (or just use the default like it was before my change), and the UI that know the Electron limitations, should inject the Electron specific path. See 97e3e1f

[brafdlog]

I understand why you want to inject the path. Its a valid solution, but in my opinion it is not worth it (passing the parameter all over). The chrome path is an internal issue of the scraper code.

An alternative is to save a const of the base path in the filesystem and each code that needs to access the file system will work with that const (this applies to configManager as well?). This will centralise this logic to one variable. In the future if we will want a mode without electron we can set this variable as part of the run.

Both solutions are valid. Up to you

[baruchiro]

I'm taking your suggestion mainly because the reason this path is not only related just to chrome. But now I see it affects only on the high-level, since you still need to get the resolved path to give it to the scraper (you also can use the download-chromium again only to resolve it).
Nevermind, the important thing is to not get stuck on these changeable things.

We need something like DependencyInjection, I don't know how implementing this design pattern in JS, if any.

Need to use this path in #173, I will comment there.