Package managers

[fredck]

There should be clarity on how we expect CKEditor 5 to be used with package managers:

• Installation of preset builds.
• Installation of custom builds.
• Installation of plugins, themes, skins, etc.

Easy upgrading is ofc a related feature.

[Reinmar]

So, I think it's pretty obvious that:

• we need a specialised builder for CKEditor (which we already have and which we'll definitely develop further to handle some development specific stuff),
• CKEditor must be built because its source version will be way more than 100 files,
• plugins must be built, because again, there will too many plugins, dependencies between them and too many files in some of the plugins, so overall even requiring a single plugin may result with loading dozens of other files.

This means that: developers will need to build customised CKEditor's packages for their use. We allowed that in CKEditor 4, but IMO we must enforce this approach even further. Developers are lazy, and I understand that, but at the end it's we who lose because we are blamed for being bloated.

We may however:

• (BAD IDEA) have some presets like we do today and those can be available through package managers; I'm not a big fan of this though, because:
  • developers tend to be lazy and instead of building some customised package they choose the biggest one and just don't use half of the stuff,
  • it's more things to maintain and it's confusing what's available where,
  • if you miss one plugin in the existing preset you start using unoptimised version of the editor,
  • it discourages writing your own modules, customising editor, etc.
• allow building set of plugins separately from other sets and from the core; the goal should be to limit number of files but still allow adding some plugins without rebuilding the whole package; then we could publish such sets on package managers.

But most importantly we need a very simple building step. In CKEditor 5 it will only require Node.JS, defining your preset and running two or three simple commands. In my extremism I would even propose that we don't publish ANY built packages on package managers.

[fredck]

I was wondering if our builder could not be integrated with package managers, enabling exactly what you're talking about. Anyway, I don't have enough expertise on the topic. Just leaving the comment here for research.

[luzfcb]

I'm new with CKEditor4 (and Javascript ) and I am interested in what is being planned for CKEditor5.

Currently, I'm using https://github.com/django-ckeditor/django-ckeditor into my project.

I think I did exactly in django-ckeditor/django-ckeditor#212 as @Reinmar said:

• developers tend to be lazy and instead of building some customised package they choose the biggest one and just don't use half of the stuff,

but I only did it because had not understood that the recommended architecture is distribute ckeditor + plugins in a monolithic js file (correct me if I am wrong)

the questions are:

1 - What is the recommended way, that packages like django-ckeditor, distribute the new CKEditor5 + some selected plugins?

• a) CKEditor5 will provide a tool to download ckeditor5-core, "ckeditor5-ui", some selected plugins and build? ( the packages like django-ckeditor could use this tool to generate the custom build) ( maybe that's outside the scope of ckeditor )

2 - programmatically or via the command line or any API, how could you get the dependencies tree of a plugin?
how I discover if the plugin is already in my monolithic version of ckeditor?
(currently, it is frustrating http://ckeditor.com/addons/plugins/ forces me to click download to show the dependencies of a plugin, which may have other dependencies and other, and other....)

Sorry my bad English.

[Reinmar]

I think I did exactly in django-ckeditor/django-ckeditor#212 as @Reinmar said:

developers tend to be lazy and instead of building some customised package they choose the biggest one and just don't use half of the stuff,

I think that you did what >90% of developers using CKEditor 4 did. And I didn't mean that developer's laziness is to be blamed. The biggest problem (the root of it) is that CKEditor 4 does not guide you, does not enforce some correct behaviours and does not have proper tools (e.g. there's a builder, but it requires Java and it's hardly extensible).

With CKEditor 5 we'll definitely fix the builder thing (now Node.JS based) and we will definitely create the documentation with focus put on how to deal correctly with CKEditor's super-modularity. My point here is that we should also take some additional precautions to save developers from failing into the same "laziness". For instance, stop proposing any packages that pretend to be ready-to-use.

So, we could for instance propose something like this:

1. NPM-based modularity

   This is the most important thing in this puzzle. All the dependency and version resolving, gitology (modules installation) will be handled by NPM. So the typical development will start with this:

   > git clone git@github.com:ckeditor/ckeditor5.git
   > cd ckeditor5
   # Now, add dependencies (plugins) to package.json or check out to some branch
   # of the ckeditor5 repo (or its fork) which defines all dependencies. For example:
   > git co super-preset-with-lots-of-cheese
   > npm install
   > grunt build
   

   And voila! NPM installed all plugins with all its dependencies and our builder combined all that.

   Now, for the development purposes you want all the modules (plugins) to be local repositories symlinked inside ckeditor5/node_modules. That will be handled by our tool on which we already started working (Tools for project related task ckeditor5#36).

2. Online configurator

   Currently we have the online builder, but that's quite expensive to have (to not kill our machines we needed to give up some useful goodies such as source maps). At the same time, having the addons repo and an easy way to choose plugins you need is very important. Therefore, instead of having an online builder we can have an online configurator. It would do everything the online builder does without the last step which is building. So in other words it will produce the package.json or a ready-to-use ckeditor5/ directory.

[Reinmar]

I posted a thread for presets in #135.

[Reinmar]

Cleaning up outdated discussions. See #186