Repository navigation
plotly core (a community vote for a simple wrapper to plotly.js) #2484
Description
Hello, long time user of plotly.R here. I thought this issue could start the discussion to split up the package into a core and a full ggplotly supported package.
As many have noted, I also started using plotly from the ggplot2 interface of ggplotly,
but as times are changing, and I am getting to understand the drawbacks of wrapping things through ggplot more,
we are moving more and more away from it.
In our RiboCrypt app, we have for optimizations reasons removed all ggplotly calls and transformed to native plot_ly() calls. We experiment with optimizations like pre-building plotly template objects, to speed up "time to user see something useful".
And since this is an app for complicated genomics, R/bioconductor is still a far better fit than python.
A problem has been the last few year that new plotly.R versions break stuff, so I have to keep version set to a version I know works. Problem is that new version needs to pass not just plotly.js tests, but also ggplotly tests for regression, so it is currently much more complicated than it needs to be.
I vote for a clean split of the package, for existing popular R package doing this, see for example the fst package, which has fst and fstcore
plotlycore: Simple wrapper to plotly.js
plotly: Uses plotlycore + ggplotly interface.
This way I think it is more safe especially for people using it for actual production apps and not just scripting.
I thought we could discuss here what people have noticed lately, what the relevant goals of current maintainers are, what resources exist to do this etc.
Activity
MLopez-Ibanez commentedon Mar 29, 2026
I see your proposed split as a good idea, as it may get more people contributing to plotly.R. But if you want to see such a split, you would need to create it. As far as I can tell, the only maintainer of plotly.R is @cpsievert and he barely has time to keep the package available in CRAN. There's no "community" of developers of plotly.R that can make such a decision. You would need to create the community by starting the project.
msummersgill commentedon Apr 13, 2026
I came to similar conclusions about the challenge of supporting upstream changes from both ggplot2 and plotly.js and wrote them up here, I actually tested the concept in this branch and validated it could work in a fairly straightforward manner.
That being said - I have major reservations about a fork without Carson's support and a corresponding refactor of the existing plotly package to import plotly-core that will prevent redundant work in the future. Posit has made a commitment to continue supporting supporting the R plotly package, and the relationships between Carson, folks at Posit, and the Plotly organization played an important role in averting a planned deprecation of Plotly R support entirely - an independent fork should be considered an absolute last resort and does not feel justified in this scenario.
One challenge I would make to the author is to open issues documenting the problems underlying the assertion that "new plotly.R versions break stuff". From what I can see on the issue backlog, such concerns have not been raised, and my observation has been that Carson has taken backwards compatibility quite seriously and avoided breaking changes over the years. If there are such issues, others are likely affected and the community would certainly benefit from a bug report that could be reviewed, or even better, a PR with a proposed solution.
msummersgill commentedon May 1, 2026
Given this issue has been open for a month without @Roleren opening an issue to support the assertion "new plotly.R versions break stuff" , I personally would move to close this issue.
I don't fundamentally disagree that splitting out the plotly API wrapping and ggplot2 interface might make sense, but I am not going to jump on board to a fork from someone who hasn't contributed to the package as it exists today, much less opened an issue describing a problem.
Roleren commentedon May 3, 2026
So for our web app, in our Docker init file we use:
RUN Rscript -e "remotes::install_version('plotly', version = '4.11.0', repos ='https://cloud.r-project.org')"
This is simply because 4.12.0 makes this change (written in the plotly NEWS file):
Editable selections: Persistent and editable selections over cartesian subplots with editSelection config option
I made my own version of this way back, using a mix of R, shiny and plotly event listeners, and now 4.12.0 breaks my version. (I get some infinite state loop swapping, as plotly.js now listens on more events than it used to)
These things happen from time to time and I have to revert to older versions until I can fix it on my end. It is usually some event listener bug.
Would just make it easier to contribute, understand what is going on if we had the split.
msummersgill commentedon May 4, 2026
That breaking change came from bumping the plotly.js version from
v2.11.1(released in May 2022) tov2.25.2(released in August 2023) in response to #2463 to close out a CVE.Carson deliberately bumped to the minimum viable upstream plotly.js that closed the vulnerability instead of updating to the latest plotly.js release at the time (
v3.3.1) to minimize possible scope of breaking changes. Keeping up with upstream plotly.js changes without introducing breaking changes in the R package is a hard task (i.e.plotly.js v2.35.0 which deprecated mapbox altogether!) and his hand was effectively forced on this one by a non-trivial security issue.It sounds like you have been effectively maintaining a personal fork for some time with features that the rest of the community might find valuable. If you were willing to open a PR and get those kind of changes along with test coverage into the plotly.R repo, then Carson could have had some visibility of the impact associated with the plotly.js update in addition to all the other things he documented testing in #2471.
Your experience does sound really frustrating. However, I have a really hard time understanding how forking the repo improves the situation.
If anything, a "plotly-core" repo that stays more up-to-date with the upstream plotly.js releases to take advantage of new features and bug fixes is going to cause more breaking changes, not less, unless users open bug reports and test coverage expands over time.
cpsievert commentedon May 4, 2026
Thanks for the thoughtful response @msummersgill -- I strongly agree with everything you've said here (and elsewhere :))
I think it would make a lot of sense to have a minimal
plotlyjspackage with minimal dependencies and functionality. That said, that wouldn't necessarily solve your problem -- even in that case,plotlywould still likely require the latest version ofplotlyjsto reduce the surface area that it needs to support.I strongly encourage you to adopt an environment management tool like renv. This sort of problem is not unique to Plotly. Pinning dependencies for apps in production is a standard practice in most other languages.