Explain the problems with publishing to npm

[johannesschaffer]

I quickly tried it locally to make the source code here a library and didn't have any problems (couldn't fully test however because of the previous issue I raised here) The main problem with the current approach of copying the source code over are the dependencies. Not only do they clutter the package.json but you also use outdated version for e.g. payload, which potentially interfere / break your plugin

[AlessioGr]

I quickly tried it locally to make the source code here a library and didn't have any problems (couldn't fully test however because of the previous issue I raised here) The main problem with the current approach of copying the source code over are the dependencies. Not only do they clutter the package.json but you also use outdated version for e.g. payload, which potentially interfere / break your plugin

I mean, you're totally free to use any newer payload version in your project. I don't quite understand how that would interfere. But generally, I agree, it's no optimal solution.

As of recently, installing the plugin via npm actually works mostly! The only issue left to fix is that the drawer for upload fields does not work yet. So if you don't care about images in your editor, feel free to install it like that! Definitely want to fix that last issue too, so I can finally recommend installing it via npm ^^

[johannesschaffer]

Ok;) I thought because you specified an exact version of payload and other dependencies ("1.6.15" instead of "^1.6.15") there might be problems with newer versions. If that's not the case I recommend changing the versions to the latter

[johannesschaffer]

Mind publishing the plugin already and fixing that bug later in a PATCH version? If you release it as a <1.0.0 version no-one should expect stability/production-readiness

[AlessioGr]

Ok;) I thought because you specified an exact version of payload and other dependencies ("1.6.15" instead of "^1.6.15") there might be problems with newer versions. If that's not the case I recommend changing the versions to the latter

Oh I only did that because I like having more control over what exact version installs. Just personal preference. But you're pretty much free to use any payload version you want in your own project! These would be the dependencies you would need to copy over:

@lexical/clipboard @lexical/code @lexical/file @lexical/hashtag @lexical/headless @lexical/html @lexical/link @lexical/list @lexical/mark @lexical/markdown @lexical/overflow @lexical/plain-text @lexical/react @lexical/rich-text @lexical/selection @lexical/table @lexical/utils katex lodash

[AlessioGr]

Mind publishing the plugin already and fixing that bug later in a PATCH version? If you release it as a <1.0.0 version no-one should expect stability/production-readiness

It's already online! But I think it's better to release a 1.0.0 once I get uploads to work when it's installed via npm. Don't wanna release a 1.0 if it throws an error every time you try to open the upload modal.

Maybe I can take a closer look later today and see if I can fix it

[johannesschaffer]

Oh I only did that because I like having more control over what exact version installs. Just personal preference. But you're pretty much free to use any payload version you want in your own project! These would be the dependencies you would need to copy over:

The problem is if you have an exact version as a peerDependency in a (npm) library I'm not really free to use a newer version;(

[johannesschaffer]

It's already online! But I think it's better to release a 1.0.0 once I get uploads to work when it's installed via npm. Don't wanna release a 1.0 if it throws an error every time you try to open the upload modal.

Oh, my bad, didn't see it. And yeah, that's exactly what I was saying, publishing it as a version below 1 (<1.0.0)

[AlessioGr]

Oh I only did that because I like having more control over what exact version installs. Just personal preference. But you're pretty much free to use any payload version you want in your own project! These would be the dependencies you would need to copy over:

The problem is if you have an exact version as a peerDependency in a (npm) library I'm not really free to use a newer version;(

Aaah now I understand - you're totally right! Just fixed that and published that as 0.0.23 :)

[johannesschaffer]

Perfect;) I would still suggest you to either explain the problems (the problem with the Modal) or remove the "[maybe someone can help to fix the publishing]" from the README.md. I would recommend to leave this issue open until it's fixed/published in case other newcomers are wondering the same thing as I did

[AlessioGr]

@johannesschaffer Just fixed that! You can now, finally install the plugin using yarn! Let me know if any issues pop up when you do that

[johannesschaffer]

Only with yarn? Does it work with npm? I had it however already working for a few days now (didn't need the image/upload capabilities). However, like I said in the other issue, I had to use pnpm for the monorepo because of the hardcoded "node_modules" path in ths scss files

[AlessioGr]

Only with yarn? Does it work with npm? I had it however already working for a few days now (didn't need the image/upload capabilities). However, like I said in the other issue, I had to use pnpm for the monorepo because of the hardcoded "node_modules" path in ths scss files

Should work with npm as well! I do think yarn works better with payload in general, though. Images / uploads should now work as well!

Not sure how to fix the SCSS issue as of now. Will have to experiment with that!

[johannesschaffer]

Maybe bundle the scss from payload, so it doesn't need it as a peer dependency? Just have to make sure tree shaking works good or maybe exclude the other files via package.json? Regardless, that's not the right place to discuss that 😅

[johannesschaffer]

If it's all working now, why didn't you release it as 1.0.0?

[AlessioGr]

If it's all working now, why didn't you release it as 1.0.0?

I was thinking I'll wait until #5 is fixed until I release 1.0.0. Hopefully #4 as well. Both bugs in lexical itself which are kinda annoying.

Also wanted to look at potentially fixing #1 . Felt a bit bad releasing it as 1.0.0 with those open

[johannesschaffer]

Sounds good;) Hope you (or lexical) will get there soon 🚀. Love the plugin, but obviously can't use it in production until it reaches 1.0.0. Looks very promising though. Actually, making it fully modular (like described in the Github discussion) would also be necessary for me to use it in production. Especially the buttons at the bottom right are too irritating for users.

[AlessioGr]

Sounds good;) Hope you (or lexical) will get there soon 🚀. Love the plugin, but obviously can't use it in production until it reaches 1.0.0. Looks very promising though. Actually, making it fully modular (like described in the Github discussion) would also be necessary for me to use it in production. Especially the buttons at the bottom right are too irritating for users.

Thank you!! I'm wondering: can I technically even release a 1.0.0 then, considering lexical itself didn't even reach 1.0.0? 😅 I'd say it's better to evaluate if it's production-ready on a case-by-case basis (=> can you live with the current issues?)

Will definitely strive towards full modularity as well!

[AlessioGr]

Also: thank you a lot for opening all these issues. Helps me a lot to keep track of things!

[johannesschaffer]

You can of course release 1.0.0 even when dependencies are not production ready. If you, as the plugin developer, can guarantee stability of the plugin, nothing else matters (no matter how you do it). Look at Next.js (which is HUGE). They vendor the experimental version of React (@next) with the stable version of Next

[johannesschaffer]

Also: thank you a lot for opening all these issues. Helps me a lot to keep track of things!

No problem (like actually not;). I usually stop raising issued when repos start requiring repro URLs;) (like payload now). I'm also working on a bit more comprehensive serializer library for lexical, which might be a replacement for copy/pasting the code from your serializer-example, eventually 🤷 - BTW, I noticed you're from Germany. Me too;)

[johannesschaffer]

@AlessioGr Just to follow up on my previous comment: I published my serializer to @johannesschaffer/lexical-utils. Under the directory /utils is a function serialize(). So the import would be `import {serialize} from "@johannesschaffer/lexical-utils/utils". It supports all major elements, theming & is fully typesafe. The GitHub repo is here: https://github.com/johannesschaffer/lexical-utils. PRs & Issues are welcome.