Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include module versions #117

Open
ryzokuken opened this issue May 8, 2021 · 11 comments
Open

Include module versions #117

ryzokuken opened this issue May 8, 2021 · 11 comments

Comments

@ryzokuken
Copy link

Include versions of the plugins that won't pollute the window namespace and instead are exposed as ES Modules. Folks could use bundlers like webpack in order to import and use the plugins cleanly then.

@rajgoel
Copy link
Owner

rajgoel commented May 10, 2021

@ryzokuken: Thanks for bringing this to my attention. Unfortunately, I do not have a clue about what you are talking (no experience with ES modules/bundlers so far). More details would be great or even a PR?

@ryzokuken
Copy link
Author

I mean a major release of the package could export the different plugins as JavaScript modules instead of setting to the window object.

so instead of window.RevealChart = ..., you'd have export default RevealChart and folks can import them using import statements (import RevealChart from 'reveal.js-plugins/chart';).

@rajgoel
Copy link
Owner

rajgoel commented May 10, 2021

Ok, I get the idea. Could you create a PR (at least for one of the plugins)? So that I can review a tested version to see whether there are any side-effects?

@ryzokuken
Copy link
Author

@rajgoel sure, I'll try to do that ASAP.

@rajgoel
Copy link
Owner

rajgoel commented May 10, 2021

perfect, thanks!

@ryzokuken
Copy link
Author

ryzokuken commented May 10, 2021

Now that I think about it, given that each plugin has different "versions" and since they're not dependent on each other (are they?), why isn't each plugin a separate module?

@rajgoel
Copy link
Owner

rajgoel commented May 10, 2021

They are all in the same repository for (personal) convenience reasons, so that I always have all my plugins in one place. The "versions" of the plugins are more or less arbitrary: Concering the release number of the repository, the first two digits are now aligned with the reveal.js-release, the last digit is a counter. This might not be the best choice, but it evolved this way and I would need a strong argument to change this.

@ryzokuken
Copy link
Author

@rajgoel I understand completely, I was just intrigued.

I've been only starting to dive deep into reveal.js and its close ecosystem for a couple of days now and it feels really interesting! For better or for worse, JS devs write code very differently these days, and you might like to update the project to reflect that. You don't have to though, but maybe it'll be helpful. I will try to quickly make an opinionated PR for a single plugin so you could review and give your thoughts.

Regarding keeping things together, I certainly understand. You don't have to necessarily split the repo though, you can also keep multiple npm packages inside a single repo, but it will take away the ability of users to install the package directly from GitHub.

@rajgoel
Copy link
Owner

rajgoel commented May 10, 2021

I am always open to learn about JS ecosystems, but at the same time have little time to invest in this side-project and focus mostly on functionality. Anything that eases my learning process is very welcome :-)

@ryzokuken
Copy link
Author

@rajgoel totally understandable! Check out https://exploringjs.com/impatient-js/ch_modules.html.

@RKelln
Copy link

RKelln commented Jan 4, 2022

I'm new to JS modules too, but took a stab at a first pass for the audio-slideshow plugin which I'm attempting to use with revealjs-vite project. You can see some of the work here: RKelln@1527c9d

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants