aem-vite / vite-aem-plugin

A proxy server and starter kit for using Vite with Adobe Experience Manager.
https://aemvite.dev/guide/front-end/vite-plugin/
Apache License 2.0
10 stars 2 forks source link

Troubles with clientlibsExpression RegEx #9

Closed stevenwoodson closed 4 months ago

stevenwoodson commented 4 months ago

Hi @cshawaus,

First I wanted to thank you for pulling together this project. I was so excited to see a way forward to make use of Vite in AEM. I've seen first hand how much faster it is at HMR and builds than Webpack and really wanted to take advantage of that for future projects.

My problem

As I was initially setting up my project, I noticed I wasn't able to see changes reflected on the Vite server. After quite a bit of fiddling with both my settings and my folder structure I finally decided to dive into the plugin source to see if I could identify where I was going wrong.

Turns out, my compiled CSS and JS files coming from AEM have a large hash at the end of the name. I understand this is something of a standard for applications hosted with Adobe Cloud Service. For example:

Half-solution

After digging in a bit I found this RegEx that looks for these files to replace them with the Vite-sourced versions. My trouble was that this particular RegEx wasn't finding files with the cache busting hash between the name and extension like above.

By changing that RegEx in two places, I was then able to see it working. I had to change:

All together, my changed RegEx looks like this: <(?:script|link).*(?:src|href)="${options.clientlibsExpression ?? options.publicPath}.(.*).?(?:css|js)"(([\\w+])=['"]([^'"]*)['"][^>]*>|[^>]*(?:><\/script>|>))

Questions

Thanks again! Steve

Tyler-Brenneman commented 4 months ago

Hi,

I ran into similar issue and noticed there is the undocumented option clientlibsExpression.

By setting this option I was able to add the regexp you have to properly match.

ex:

    plugins: [
      react(),
      viteForAem({
        ...
        publicPath: '/etc.clientlibs/<app>/clientlibs/<client-lib>',
        clientlibsExpression: '/etc.clientlibs/<app>/clientlibs/<client-lib>(.*)',
      }),
    ],
stevenwoodson commented 4 months ago

Hey @Tyler-Brenneman, thanks for commenting!

I noticed the clientlibsExpression option too as I was digging into the code, unfortunately that only covers the filepath (the first of the two changes I noted in my initial comment) and not the fact that CSS files aren't matching (the second change).

So I could use that for the former but I'm fairly sure the latter would need to be a code change here.

cshawaus commented 4 months ago

@stevenwoodson Apologies for the delay in responding.

I use a non-standard ClientLibs configuration that turns off long cache as it doesn't make sense in development environments. However, that is a poor choice, as what I do is not a default expectation.

If things are not too busy over the weekend, I will get this fixed and released by the end of the week or early next week.

stevenwoodson commented 4 months ago

That sounds great Chris, thank you!

I'll, of course, be around to help test it out, but let me know if there's anything I can do to help further.

cshawaus commented 4 months ago

@stevenwoodson I have released v5.0.5 which includes support for:

stevenwoodson commented 4 months ago

Fantastic, thanks for jumping on this so quickly, I really appreciate it!

Just upgraded to 5.0.5 and so far so good, can confirm that CSS and JS files are updating realtime without any manual edits. I think this one is good to close!

Tyler-Brenneman commented 4 months ago

Can confirm it fixed the issue for me aswell. No longer need to add my custom clientlibsExpression