Move eslint to devDependencies

[wesleybl]

No description provided.

[netlify]

✅ Deploy Preview for volto ready!

Name	Link
🔨 Latest commit	bcf3b77
🔍 Latest deploy log	https://app.netlify.com/sites/volto/deploys/64b68b6cefb8f0000862ce38
😎 Deploy Preview	https://deploy-preview-4983--volto.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[cypress]

Passing run #6435 ↗︎

0

529

20

0

0

Details:

Move eslint to devDependencies
Project: Volto	Commit: bcf3b77863
Status: Passed	Duration: 18:38 💡
Started: Jul 18, 2023 12:57 PM	Ended: Jul 18, 2023 1:15 PM

_{This comment has been generated by cypress-bot as a result of this project's GitHub integration settings.}

[sneridagh]

@wesleybl this being in deps has a reason :) How are you going to install ESlint now in the projects if it's not as a direct dependency? Like this one, there is a lot of deps in the same situation... the duality library/framework of Volto is difficult, and there is nothing out there like it. We could move it to its own package (as Razzle and others do), then install that package in the project, but we never made that move.

[davisagli]

@wesleybl Victor is right. For now, volto's devDependencies can only include packages that are used for developing volto itself but not for developing volto-based projects. If we want to split off the packages that are needed for developing volto-based projects but not at runtime, then we need a new package, @plone/volto-dev-utils or something like that.

[wesleybl]

@sneridagh @davisagli wouldn't it be the case if you put these packages in the generator and put an update note?

[sneridagh]

The thing is that maintain the ones in the generator is a pain. The ones that are there is because it's strictly necessary for other reasons. We would like to reduce that list, instead of increasing it.

The ideal scenario would be to have such a dev package that we mentioned, and a code-mod like script/process to update projects automatically.

[wesleybl]

@sneridagh you say why are two places to update? Isn't having a new package that needs publishing more complicated?

[sneridagh]

@wesleybl yes,

1. It's a burden to maintain, because they have to be exactly the same within the same build, in order to avoid hoisting problems
2. You can only change them in a breaking change then (since you have to inform them to the users, and require action in their builds, which in turn, it's also a burden and an annoyance for integrators).
3. Every time you change it, you have to inform and make users update their builds and boilerplates
4. One of the major painpoints that the integrators are complaining about is the amount of changes that you have to do when upgrading Volto to a major version. So we are not making this worse.

For these all reasons, sorry, this is not going to happen now. Believe me, we've been there thinking in a way to improve this situation quite some time ago before you did and yourself why it's like this. The only acceptable way to do this is building the pieces that we've pointed out in the other comments. Maybe could look into build them if you are up to, it would be an awesome and valuable addition.

[wesleybl]

@sneridagh I can create a metapackage @plone/volto-dev-utils, as suggested by @davisagli, with just a package.json in the packages folder. Would it be this?

[sneridagh]

@wesleybl we can consider it, maybe you can give it a try. Not sure about the right naming. Let's allow @tiberiuichim to weigh in, since I know that he was trying it some time ago.

[wesleybl]

Ref: #5872

[wesleybl]

Done in #5879