Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Preact CLI or WMR? #867

Closed
Pringels opened this issue Sep 10, 2021 · 3 comments
Closed

Preact CLI or WMR? #867

Pringels opened this issue Sep 10, 2021 · 3 comments

Comments

@Pringels
Copy link

Note: This isn't a bug or a feature request. Please let me know if you would like me to use another channel to ask this question and I will close this issue.

I'm a bit unsure as to which build tool I should be using for my preact project. It seems as though the differences are a matter of personal preference: #128 (comment)

But beyond that it isn't really clear to me which tool would be best to adopt in the long-term. I get the impression that preact-cli is no longer being actively worked on: preactjs/preact-cli#1579 (comment)

My current project was set up using preact-cli. I've been happily using it for close to two years now. Lately though I've been experiencing many issues with legacy dependencies. I have to manually pin versions of an increasing number of modules to prevent my builds from breaking.

Today I finally tried to migrate the project to WMR. The problem is that a huge number of my project's direct and transient dependencies are not all ESM compatible. I understand that the entire JS community is dealing with this problem right now, but this means that I cannot move to WMR for the foreseeable future.

So it almost seems like preact-cli is approaching deprecation while WSR is too modern to be stable with userland deps 😄

Is this an accurate assessment? Does preact-cli still have a future? Should I just wait it out?

Sorry if this comes across as overly negative. I love using Preact and I truly appreciate the effort you're putting into it!

@marvinhagemeister
Copy link
Member

We don't advertise WMR yet, as we feel like there are some remaining friction points to solve when it comes to bigger projects and interop with older dependencies as you have mentioned. We've been using WMR in a couple small to medium projects and we've been very happy with that ourselves, but for bigger projects it's not there yet.

The reason preact-cli hasn't received as much love as we'd like is because it's very time consuming to keep up with all the breakage between different loaders and plugins in the webpack ecosystem. We've had several attempts of staying on top there, but there is just no end to poking loader authors or submitting PRs to them. Don't get me wrong, preact-cli is a fantastic thing and has served us well with current projects, but we're eager to replace it with something else in the future. Hopefully something that isn't as demanding on maintenance.

At the time of this writing these are the options to pick from:

  • preact-cli use this if you heavily rely on webpack-specific behavior or compilation.
  • WMR: awesome for smaller to medium projects, but there are some interop issues with non-ESM dependencies
  • vite: very much inspired by WMR (copied our plugin system, and we backported some of their improvements back to WMR), has better support for older dependencies right now than WMR
  • parcel: haven't used this myself with Preact in particular, but heard good things about it
  • nextjs: another webpack-based tool that's very popular with folks coming from React

Reading your post it seems like you'd be most happy with either nextjs or vite. nextjs has a little better support for legacy dependencies, whereas vite is faster and is more modern all around with a much better plugin system.

In either way commonjs or umd-style dependencies are definitely on it's way out. There are often newer ESM alternatives around. So long-term it might be worth it either way to switch to newer ESM alternatives of your dependencies.

Whatever you'll go with I'd love to hear more about the specific issues you ran into with WMR. Is it something that's already in the issue tracker here? Something we can fix?

@developit
Copy link
Member

@Pringels Any dependencies in particular that are giving you trouble when trying to migrate? We do some transformation for CommonJS, but it's not as robust as full ahead-of-time bundlers implement (or Vite's dependency prebundling for that matter).

I've migrated a couple projects from preact-cli to WMR and generally the tricky spots are where I had customized preact-cli (ignoring deps, "noParse", etc) - I haven't run into incompatibility with libraries much. Curious to know where its falling over for you.

@Pringels
Copy link
Author

@marvinhagemeister @developit thank you for responses!

I tried out vite and you're right: it is indeed a great fit for my project. I was hoping to use a "batteries included" tool built by the preact team as I don't enjoy setting up custom build configs from scratch. But it looks like the build tool ecosystem has improved a lot since the last time I had to manually configure webpack. Goes to show how quickly one can fall behind :)

Most of the issues I had were with libraries that don't support ESM. I also experienced an issue where some packages installed to node_modules were missing subdirectories and package.json files. I have no idea how or why that kept happening. I will try to reproduce it consistently and create an issue.

@developit the biggest incompatibility I have with preact-cli is lack of support for postcss 8 (preactjs/preact-cli#1560).
I investigated this a while back and as far as I can tell the current release of the critters library still requires postcss 7 (which has been removed but not released yet: GoogleChromeLabs/critters#61 (comment))

Thank you both for taking the time to respond. Vite seems like a great alternative for now :) I will document any issues I had with WMR and preact-cli

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants