Deprecations issued in Volto 18

[sneridagh]

PLIP (Plone Improvement Proposal)

Responsible Persons

Proposer: Víctor Fernández de Alba (@sneridagh)

Seconder: Timo Stollenwerk (@tisto)

Abstract

It is needed to push for some breaking changes in the upcoming versions of Plone/Volto. So we need to start mark as deprecated things and point people to the right way of doing things. By doing this, we inform people that this is happening soon, and that they have the option to start working in their projects avoiding pitfalls and using our best practices and recommendations already today so they can be prepared for the near future.

Deprecations

SemanticUI

SemanticUI library is not maintained anymore and will be removed in Plone 7.

Any usage in add-ons and projects is discouraged and not recommended.

Related PLIPs:

• SemanticUI Free CMSUI #6321
• Complete removal of Semantic UI from Volto #6323

Alternatives

Use any supported component framework or supported of your choice for implementing new components, specially in the public theme side. In the case that you create new widgets or components for use them in the CMSUI (non-public side) it is recommended that you use @plone/components library as an alternative, although it's still in development phase and has still to be finished in the next months.

lodash

lodash has not received any updates since 2021 which makes it kind of concerning too in terms of future maintainability. Lots of lodash utility helpers can be replaced nowadays by vanila ES. It is decided that will be removed from Plone 7 since it has performance issues (bloated bundles) and it's not prepared for ESM. Plone 7 will use the lodash-es library (ESM ready) instead and it will be replaced by modern vanilla ES alternatives whenever possible.

Alternatives

The usage of lodash is becoming not necessary, since over time vanilla JS/ES features has make them obsolete. Take a look at this URL to check if you have better alternatives every time that you want to use lodash:

https://github.com/you-dont-need/You-Dont-Need-Lodash-Underscore
https://javascript.plainenglish.io/you-dont-need-lodash-how-i-gave-up-lodash-693c8b96a07c

If you still need some of its utilities you can use lodash-es instead.

@loadable/component and Volto Loadables framework

@loadable/component and Volto Loadables framework will be removed from Plone 7 because it's a Webpack only library and it does not have Vite plugin support.

Overall, from React 18 this library is not necessary since it has the initial implementation of the "concurrent mode". React 19 will improve even add more the features around it.

Alternatives

The recommendation is to use plain React 18 lazy load features and its idiom for lazy load components.

const myLazyComponent = lazy(()=> import('@plone/volto/components/theme/MyLazyComponent/MyLazyComponent'))

const RandomComponent = (props) => (
    <React.Suspense>
        <MyLazyComponent />
    </React.Suspense>
)

There's no support for pre-loading or lazy load entire libraries as in @loadable/component but there would not be really necessary anymore, once we get rid of all the barrel imports files (see next deprecation).

Removal of all existing main barrel imports files (src/components/index.js, src/helpers/index.js, src/actions/index.js)

Volto had this barrel imports (centralized files where other imports are re-exported in order to improve the developer user experience since the developer only has to remember to import from the re-exported place, not the full path).

It became a bad practice, since bundlers rely on the import pathway in order to determine if bundle code together or not. Since the barrel imports direct import all the code, a lot of imports ended up in the same main chunk of code. Modern bundlers like Vite also use that technique, so it heavily relies on this. We have to remove the barrel imports in order to increase the natural number of chunks that Volto divides on (specially on routes), and the code splitting is done the right and natural way.

This will force us to rewrite all the imports everywhere (core, projects and add-ons) once we implement it.

Alternative

We can start implementing only direct imports in our code right away, preparing for the upcoming change, so we don't have to in the future.

-import { BodyClass } from '@plone/volto/helpers';
+import BodyClass from '@plone/volto/helpers/BodyClass/BodyClass';

Once this is implemented, a codemod will be provided to fulfill a smooth migration.

@plone/generator-volto

The Node.js-based Volto project boilerplate generator is deprecated from Volto 18 onwards. Although you can still migrate your project to Volto 18 using this boilerplate, is recommended that you migrate to use Cookieplone.

After the release of Volto 18, it will be marked as deprecated, archived, and it won't receive any further updates.

Alternative

Migrate your project to use a Cookieplone boilerplate.

Volto project configurations

It's been a while that you can configure Volto using an add-on. The "project" way, so you configure Volto using src/config.js in your project is deprecated and will be removed in Volto 19.

#6396

Alternative

It's recommended and hevily encouraged that you do all your project configuration in a policy add-on. You can move your project to use Cookieplone which provide the necessary boilerplate for it.

Proposal & Implementation

We issue the deprecation messages in the upgrade guide of Volto 18.

@stevepiercy do you think that this should go somewhere else?

Adding this as a PLIP so the Volto Team can review it and approve them in the next meeting.

Deliverables

Documentation in the Volto 18 upgrade guide.

[stevepiercy]

Deprecation messages should also be exposed to the developer while developing, as well as the upgrade guide, because that's where they focus.

We also need to review any places in the documentation where developers may refer, including the following.

• Development
• Configuration
• Theming
• Volto add-ons

The foregoing are merely parts to review. In those parts, we need to identify which pages, and sections in each page, need to be updated, and create a task, issue, or pull request for each item and add it to this PLIP's task list or project board.

In the main documentation, @davisagli and I are working on an overhaul of installation methods in plone/documentation#1714

[sneridagh]

Let's keep it open FTR.