Should I use webpack or another option?

InDesign
1

Hello,

I am doing some research trying to figure out what release packaging functionality my team should use for our UXP-based plug-ins. I know that webpack and jFrog are options, but I was wondering if anyone uses anything different or has recommendations.

Thanks!

1 Like
2

I have used esbuild for my plugins recently. I have, however, also built some custom tooling around that tech stack. You can find the general approach I used in my open source Lorem Ipsum plugin for Adobe XD:

Note that some minor adjustments are needed to make it work with the new version of UDT (which I have already done for another closed source projects and will need to migrate over to the open source plugins soon).

While the UXP Developer tool has to run in the background (providing a kind of server side for the development), an esbuild plugin automatically handles loading/reloading the plugin.

To me, webpack just feels kind of clumsy / enterprise-y (in a bad way) in 2024, and given the nature of being a plugin developer, I found esbuild (with it’s very straight-forward extensibility) awesome to optimize for my workflow. There is also something to be said in favor of having build pipelines / … as editable scripts inside the project repository. And the speed esbuild provides is absolutely incredible (especially combined with automatically reloading the plugin afterwards, this gave my UXP develpment workflow a huge speed boost).

However, raw esbuild (you can’t use something like vite on top of it as vite doesn’t play nicely with UXP’s CommonJS2 modules), while highly customizable and overall very stable (in my experience) is more DIY/frickly in its nature. I still find it much easier to handle since I can see what’s going on while with webpack’s configuration abstractions, debugging configuration issues is an absolute nightmare. But this, of course, comes down to personal preference.

Other than that, I have tried rollup for UXP development in the past. That worked ok (and to me, everything feels better than webpack). But I don’t see a good reason to use it nowadays. If you want “old jack of all trades”, webpack is the best option. Otherwise, I wouldn’t want to miss the speed / light-weightedness of esbuild.

3 Likes
3

That looks interesting, @pklaschka. Thanks for sharing.

https://esbuild.github.io/

1 Like
4

Cool. I’ll look into esbuild. Thank you!

1 Like
5

I tried ESBuild for Alchemist here: alchemist/esbuild.config.js at master · jardicc/alchemist · GitHub

And it works. But I would still most likely use Webpack for my bigger private projects.

ESBuild caveats:

  • needs a trick to fix source map
  • needs a trick to generate comatible JS and CSS in minifier
  • for one project I used antDesign components version 4 and less configuration does not allow to change variable during bundling
  • and fatal flaw in my opinion is that ESBuild is fast but for TypeScript it does no type checking at all and this is intentional. And I really want it to be part of the bundling process and not relly on IDE. You can add plugin do that for you but then it slows down bundling a lot so the advantage is not so big
  • I had issue that type checking plugin tested also files not included in bundle… e.g. test files and other but that was maybe only problem with my configration… not sure. With webpack and ts-loader you will use onlyCompileBundledFiles: false to ignore files
  • I didn’t solve code obfuscation. Also you want to obfuscate only code with know-how. There is no need to obfuscate React library because it is open sourced and obfuscation costs performance.

With webpack… configuration is more difficult to do or understand, performance is slower but it can solve anything you can think of or you can make plugin or google answers.

1 Like
6

Thanks for the details @Jarda. I appreciate the effort that reply took!

Jon