Forked version, bugfixes and 32-bits R support

[erikvona]

I really needed this package to work, but encountered numerous bugs.

Bugs I encountered:

• Missing variables in glue, already reported in object 'platform' not found #429
• unknown option '--display=none', already reported in error: unknown option '--display=none' #430
• Errors when building an app on a different network drive
• devtools missing in the built app even if the app requires it (all made with {golem} do)
• R not closing properly on the app quitting

I also needed two new features:

• Setting a fixed port to allow localStorage to work
• Allowing 32-bits R installations to work with ODBC drivers present on 32-bits Windows by default.

I addressed all this in a fork (erikvona/electricShine). Since I was adding features before addressing some of these bugs, isolating the fixes and submitting pull requests for them is a bit of work for me. If you're still working on this and want help, I'll do what I can.

[ManyaoLi]

I encountered the same issue. I am waiting for the solution and will be grateful for any useful suggestions.

[blschum]

I encountered the same platform issue brought up in issue #429. When I use this forked repo ^ I encounter a new error: "Error in eval(parse(text = text, keep.source = FALSE), envir) :
object 'TCP_PORT' not found". Any ideas?

[erikvona]

@blschum Have you specified tcp_port= 1010 in electrify or some other port? The fork includes changes to set a fixed TCP port which is not optional

[jrletourneau]

Thanks for sharing this! The forked repo solved both the platform and --display=none issues for me. However, I get a new error beginning:

Error: Cannot find module 'fs/promises'

From here this should be solved by upgrading nodejs to v14+. However, in R/install_nodejs.R of the fork, it looks like it's set to install v15. Any advice appreciated.

Edit: I think the above had to do with having two versions of electricShine installed at once. electrify actually contains an argument to specify the nodejs version, so that's easy enough. My new issue is:

Error in .check_arch() :
Unfortunately 32 bit operating system builds are unsupported, if you would like to contribute to support this, that would be cool

Edit: This was a me issue. I had recently upgraded my version of R and needed to re-install Rtools.

Current error is I am trying to figure out how to resolve is:

npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! Found: webpack@5.72.0
npm ERR! node_modules/webpack
npm ERR! dev webpack@"5.60.0" from the root project
npm ERR! peer webpack@">=2" from babel-loader@8.2.3
npm ERR! node_modules/babel-loader
npm ERR! dev babel-loader@"8.2.3" from the root project
npm ERR! 1 more (css-loader)
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! dev friendly-errors-webpack-plugin@"1.7.0" from the root project
npm ERR!
npm ERR! Conflicting peer dependency: webpack@4.46.0
npm ERR! node_modules/webpack
npm ERR! peer webpack@"^2.0.0 || ^3.0.0 || ^4.0.0" from friendly-errors-webpack-plugin@1.7.0
npm ERR! node_modules/friendly-errors-webpack-plugin
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.

[erikvona]

I'm using this with node v14.17.4. I haven't touched R/install_nodejs.R (afair) and recommend manually installing node instead of letting electricShine do it. I've had some issues with more recent versions but I'm experienced in R, not node, so have difficulty debugging this. If anyone feels like fixing it + making a pull request, I'm very much open to it.

[jrletourneau]

Actually, just setting nodejs_version = "v14.17.4" resolved the above issues. Thanks! I now get a .exe in dist, and the infinite loading screen issue I had when working off the main branch is resolved as well. Now, the installed app is not actually running, but I suspect that has to do more with how I've set up my app with golem, so that's a separate issue...

[erikvona]

Ah, I'm all too familiar with that. You can open a command window, navigate to the folder the project is in (not the dist folder, the one containing package.json), and use npm run to start the application. That allows you to view errors/messages generated by node and R, which aids in troubleshooting Shiny failing to start. Note that for people not using the forked version your mileage may vary, I've made some changes to properly forward R errors.

[jrletourneau]

I got it to work! Thanks so much for the help. For future users, here is exactly what I did:

Ran erikvona's fork of electricShine with the following parameters:
electricShine::electrify(app_name = "AppName", short_description = "App Description", semantic_version = "1.0.0", build_path = tempdir(), cran_like_url = "https://cran.r-project.org", function_name = "run_app", local_package_path = "path/to/package/made/with/golem", nodejs_version = "v14.17.4")

A .exe was created, but did not run properly (gray transparency over the app and nothing happened when action buttons clicked). With node.js downloaded (directly/manually, not just via electrify), on the command line (Windows PowerShell) I navigated to the build path and ran npm run start to start the app. The logs included the R error that was preventing the app from loading properly, which had to do with how I was loading data and was solved by comments here.