Migrate to unplugin#17
Conversation
|
This PR should address the issues I'm facing with the |
Why would you need to bundle a build-time dependency?
That's not something I'm willing to go along with. |
Because we don't want to make end users have to install unplugin to use the plugin
Why? And how would you suggest to tackle the bundling of the plugin? |
Isn't that how the npm ecosystem works? You install dependencies when you need them. |
Not precisely. You install dependencies when you need them, but it is expected that these dependencies will take of bundling themselves and not require you to do it in your project. Here's a very popular unplugin, |
|
Why would users be required to bundle the unplugin dependency? Can't it just be loaded from node_modules like usual? |
|
Not if it's explicitly declared as a dependency, especially for stricter package managers like pnpm. |
|
Obviously it'd have to be declared as a dependency, yes. |
|
I sense a lot of resistance both here and in my other PR that you closed. I have no interest in trying to convince you that my approach to libraries is any better, I just want to use Lezer from ESBuild. If you're not willing to accept this PR, I will just create the unplugin in a separate repo and publish it as a separate package. |
|
That's probably for the best. Coming into a project and reorganizing stuff wholesale to fit your preferred approach is not always going to be welcome. |
|
Here it is, in case you want to add a note about it: https://www.npmjs.com/package/unplugin-lezer. It's a shame we couldn't come to a consensus. |
I drafted a solution to migrate to unplugin, but ran into some issues in the process. Since we introduce an additional build-time dependency, we need to bundle it to avoid burdening the end user. That means we no longer can simply externalize every dependency and let Node figure it out.
For that reason, I slightly edited the building logic. I decided to replace Rollup with esbuild because it's more out-of-the-box, requires no plugins and less fiddling. That brought me to the problem of the
@lezer/lrpackage which contains a./dist/constants.jsfile that actually exports nothing, and isn't mentioned in theexportsfield ofpackage.json. To proceed with this, we need to remedy those issues in@lezer/lr.Closes lezer-parser/lezer#48