Prism being contained in CodeFlask removes plugin abilities

[anna-is-cute]

I use the Custom Class plugin to namespace the Prism classes, since some of them conflict with my own CSS.

Before 1.0, CodeFlask used the Prism that I provided, meaning everything worked just fine. Now, however, CodeFlask uses its own version of Prism, meaning that I no longer can use the plugin, which breaks styling.

I see no way to interface with CodeFlask's version of Prism outside of the language functions. (I see Prism is in the global namespace, confusing me even more as to why it's included with CodeFlask) I would love to see a way to disable CodeFlask's version of Prism and be able to use my own, similar to how it was before 1.0. I can only see more issues in the future because of Prism being included in CodeFlask instead of CodeFlask depending on it.

---

This may change depending on the load order, but I have to load Prism before CodeFlask so I can add languages to it (#65 related). I suppose that I could maybe load Prism before CodeFlask, change its name to Prism2, then set CodeFlask's Prism equal to Prism2, but that seems like a gigantic hack.

Either way, I shouldn't have to (and by extension shouldn't have to force my users to) load Prism twice 😢

[kazzkiq]

It seems that Prism module, even if loaded as a dependency, ends up exposed globally.

I believe what can be done is removing it from global scope and expose it from within CodeFlask. So instead of have CodeFlask exposing certain functions from Prism, it would expose the whole Prism library, so users can use its interface as needed.

The reason why I'd like to keep Prism as a CodeFlask dependency (inside CodeFlask) is the same reason why the CSS is now embedded into CodeFlask: It's way easier to use a library that simply runs without having to add gazillions of other things around it.

But while I have strong opinions on keeping the ease of use, I do agree that CodeFlask should at least allow for more flexibility to those who need it.

So, to prevent conflict, I believe we could do something like:

// Prism exposed through CodeFlask
// So you can add languages, plugins and so on
CodeFlask.Prism.[any_prism_method_here]

// Now those instances runs with all those changes
const flask = new CodeFlask('#element', { language: 'js' });
const flask2 = new CodeFlask('#element-2', { language: 'js' });

Another option is making Prism a conditional import of CodeFlask: If there is already a Prism in window, use it as highlight engine. If there is not, load its own and expose it globally as it is today.

What do you think?

[anna-is-cute]

Ideally, I'd like to be able to load in my own Prism with plugins and extra languages and have it just work, so having it as a conditional import seems good to me. Re-exporting is an excellent solution for people who don't want to load Prism separately.

My other concern then comes from not wanting to have to download Prism twice (once for the global custom Prism, once for the one included in CodeFlask).

[kazzkiq]

I believe there is no escape from loading Prism twice here. Since it will always come with CodeFlask, and since the default behavior is to use the built-in Prism, users that want to use their own version would have to deal with this downside.

That being said, CodeFlask is ~7kb gzipped. Loading another Prism instance should add another ~4kb. That's ~11kb for a code editor, which is still at least 5x smaller than CodeMirror, for example. So I think its still doable.

[kashike]

The reason why I'd like to keep Prism as a CodeFlask dependency (inside CodeFlask) is the same reason why the CSS is now embedded into CodeFlask: It's way easier to use a library that simply runs without having to add gazillions of other things around it.

And it's another reason that makes people not want to use your library.

If I go to a coffee shop and order a plain coffee I expect a plain coffee, not a coffee with cream and sugar.

[kazzkiq]

Prism is needed for code highlight. Without it, CodeFlask isn't a proper code editor.

The base CSS is needed to make the editor work properly. Without it, no code editor.

The only code that could be considered "cream and sugar" is the theme CSS, which can be disabled in options.

I honestly can't see the deal of having those inside CodeFlask by default.

[anna-is-cute]

Maybe I like one sugar and no cream and @kashike likes two and cream. When the coffee comes with a pre-determined amount of cream and sugar, though, we don't get a choice. Maybe I don't want the extra calories or might decide I want cream sometimes but not other times. I don't really get a choice when everything is bundled and injected for me.

It makes everything marginally easier for the developer throwing together a quick project (one script element instead of two scripts and one link), but it makes it much less flexible and adds a lot of frustration for people using it for big projects.

Edit: That being said, if we can get rid of inline styles and resolve this issue, I'll be happy either way ¯\_(ツ)_/¯

[otto-dev]

Since this is still open...

• I don't think size is an issue, since the bundled .js file will only contain one re-used instance of prism. Just make sure you are using a compatible version in your own project, so that the package manager re-uses the same package. That's at least what I expect to happen / what I think you can make happen.

• For those who want to modify Prism, can't CodeFlask provide a constructor where you can inject your modified Prism instance?

• Can't CodeFlask simply re-export the Prism module, so that others can import it?

On paper the above point all seem pretty straight forward to me. Depend on CodeFlask, then use Prism, modify Prism seperately, inject Prism into CodeFlask - covers all use cases.