Full ESM compatibility #502
Replies: 5 comments
-
Announced to the Principal group |
Beta Was this translation helpful? Give feedback.
-
For those using Svelte, here is a pattern that Auro has been using to validate SSR builds. <script>
import { onMount } from 'svelte';
// elements that are ESM compliant exist in this import function
import('@aurodesignsystem/auro-button');
onMount(() => {
// elements that are not ESM compliant are loaded here
import('@aurodesignsystem/auro-dropdown');
});
</script> Running a build with Vite results in the following > vite build
vite v5.1.1 building SSR bundle for production...
✓ 79 modules transformed.
vite v5.1.1 building for production...
✓ 1303 modules transformed.
.svelte-kit/output/client/_app/version.json 0.03 kB │ gzip: 0.05 kB
.svelte-kit/output/client/.vite/manifest.json 18.35 kB │ gzip: 1.96 kB
...
|
Beta Was this translation helpful? Give feedback.
-
Learning more about SSR/ESM support there was also a lot learned about using the Vite tooling. One of the questions that came up during the SSR work was, "How do we test this to ensure ongoing compatibility?" While we can use an example Svelte site, that is a lot of overhead and manual updating to maintain. The real answer is, how do we bring SSR inside our web component repos? One answer that is an opportunity is to simply bring Vite into Auro. Here is an example project to support this idea. https://stackblitz.com/edit/vitejs-vite-eeqhdd?file=index.html&terminal=dev |
Beta Was this translation helpful? Give feedback.
-
It appears that day.js is not able or interested in addressing the larger ESM needs. I am considering a fork of the repo and updating as necessary to allow for our ESM support. |
Beta Was this translation helpful? Give feedback.
-
This was mentioned in another Discussion |
Beta Was this translation helpful? Give feedback.
-
SSR in general and SSR between React and Svelte are two VERY different things. The one main difference is that Svelte uses the Vite build tools which has a strict adherence to modern ESM standards.
So it's not an issue that we support SSR, but actually support strict ESM and Vite/Svelte by proxy.
Due to the strict ESM specification, other things need to be dealt with. One big one is popper.js. It is not strict ESM and thus any element that has a dependency on popper will not be ESM. This includes popover, dropdown, select, combobox and datepicker.
Another dependency with an issue is mark.js which is used with auro-menu. This has to do with an undefined window object during SSR processing. This is similar to an update I had to make to auro-input and it's the management of loc. AlaskaAirlines/auro-input@fa45148#diff-247b6ba6752b3b29ab8b50abe8fe8c0c157ad49f85bce9b52a605cc2edb4fa69
In the end, SSR is deeper than most let on in the community and there is some work to be done. Here is a thread from the shoelace lib in their attempts to make it SSR shoelace-style/shoelace#778
The team will have to go element by element to ensure ESM compatibility and some will be harder than others.
to communicate which elements are ESM compatible versus those who are not, look for this badge to appear on the repo's README page.
Auro ESM support checklist
Beta Was this translation helpful? Give feedback.
All reactions