Supporting ES6/ESM and TypeScript in v5.0

[ghiscoding]

I'm currently looking at possibly supporting ES6, ESM & still support <script> (iife) by using ESBuild which is very fast to build and also build minified code. Supporting both would create 2 (or 3) different folders under dist/ dedicated for each format we want to support.

For user who still prefer <script> loading (standalone as iife), it would not be a big changes for them, the only change is to their script files location, it would have to change to something like /dist/browser/. Apart from that, the usage would be exactly the same (new Slick.Grid(), ....)

The old <script> (browser) is still supported with ESBuild using iife type (iife is what SlickGrid was built with for years), our new location would be under /dist/browser/ so users would have to adjust their script locations

- <script src="../slick.grid.js"></script>
+ <script src="../dist/browser/slick.grid.js"></script>

// creating a slick grid is exactly the same
grid = new Slick.Grid("#myGrid", dataView, columns, options);

ES6/ESM

For users who want ES6/ESM, user could use imports. However with this approach, we would not have access to the Slick object and it would not be on the window object either. The advantage is better ES6 support but also smaller builds with better tree shaking and would close the old issue #41

The new ES6/ESM would be under a new location /dist/esm/ (ESM) or /dist/cjs/ (CommonJS)

- <script src="../slick.grid.js"></script>
+ <script type="module">
+ import { SlickGrid } from  '../dist/esm/slick.grid.js';

// creating a slick grid (notice the `Slick` no longer exist, we will instead import `SlickGrid` class)
- grid = new Slick.Grid("#myGrid", dataView, columns, options);
+ grid = new SlickGrid("#myGrid", dataView, columns, options);

So the question is, do we want to ship this under v4.0 as well or wait for a v5.0? This would be a bigger breaking change for users but it would bring ES6 support which was requested in an old issue #41. The small build is a really tempting feature from my point of view and there's also code that I do not use in my libs, so ES6 imports would allow me to avoid downloading code that I do not use. Also lastly another benefit would be that ESBuild also support TypeScript out of the box, so it would be as simple as changing the .js extension to .ts and the build would still work.

A disadvantage with this new feature would be that we need to run a build before seeing the changes in any of the examples, so it would take a bit more time to see the result of a code change. I'm planning to create a SPA (single page app) and use ESBuild in watch mode so that we can make code changes without having to rebuild/reload all the time (however all standalone examples would have to change)

[6pac]

My view so far has been that SlickGrid is a library that will require some tweaking and customisation before use. Therefore, I've always avoided providing a final 'build' for it, insisting that the build was part of the developer's responsibility.

Perhaps as the grid matures, providing different options as final builds would be a logical part of the package. I feel like if we do that, we should streamline what gets built somewhat, at least losing the examples and any other test code and nonessentials. Perhaps nonessentials should even be split into a separate repo or at least folder?

Sounds like this would fit in well with your suggestions. The features this would bring sound great, especially being TS-ready.

I'm just wondering if we're packing too much into a breaking release though - perhaps it would be clearer to keep v4 only to removal of jQuery, and do further structural changes in v5? It might not be good to hit consumers with too many changes all at once. On the other hand, they'll be rejigging all their dependencies with the jQuery removal, so perhaps it is the right moment to be rearranging dependencies in general?

[ghiscoding]

Perhaps as the grid matures, providing different options as final builds would be a logical part of the package. I feel like if we do that, we should streamline what gets built somewhat, at least losing the examples and any other test code and nonessentials. Perhaps nonessentials should even be split into a separate repo or at least folder?

yeah the best way to go with this would be to change all the standalone examples into a Single Page App (SPA) so that we can then use ESBuild watch mode to serve and build.

I'm just wondering if we're packing too much into a breaking release though - perhaps it would be clearer to keep v4 only to removal of jQuery, and do further structural changes in v5? It might not be good to hit consumers with too many changes all at once. On the other hand, they'll be rejigging all their dependencies with the jQuery removal, so perhaps it is the right moment to be rearranging dependencies in general?

that's pretty much why I created this discussion, I have the same feeling but at the same time it would be nice to have it ship at the same time.

The other option would be to ship ES6/ESM a few weeks later under v5, just enough time (a few weeks) just to see if any issue came up.

[6pac]

I should also mention that, being in a remote area, I sometimes work on the lib out of wifi range, ie. offline. I note that moving to the CDN references in the examples means that they all stop working when I do this.

[ghiscoding]

hmm I moved to CDN mainly to remove the fact that we're not providing Licenses for jQuery and all other external libs. If we do switch to ESBuild, we'll have to run npm install and have all dependencies installed under the node_modules folder so that would fix the CDN issue while still avoiding having 3rd party libs without licenses in the repo

[6pac]

Perfect

[6pac]

My gut feeling here is that a v5 release after a short time would be better. I think throwing too much change at consumers can potentially create confusion for them. Although it will in the end be the same level of change, having a separate release would make documentation and dealing with issues a lot clearer.

[ghiscoding]

yeah I also think that would be the best since it's probably going to take me a month or so to get this new ESBuild/TS feature. So let me test the Tree Columns thing and if all goes good, we could release a v4.0 beta version

Looks all good on my side, we are ready for v4.0 beta 🚀

[ghiscoding]

@6pac thought of providing an update on what I'm working on and got working so far on the next major... there's a lot 😉

1. standalone <script> (iife) are working, the only change is the location of the scripts are now under /dist/browser/*.js
2. ES6/ESM are also working under 2 locations /dist/cjs/*.js (CJS/ES6) and /dist/esm/*.js (ESM)
3. I found a way to use fallback when internet is disconnected, just added a 10 lines script that first try SortableJS CDN or if not found will revert to node_modules/sortablejs when internet is not available
4. I'm working on a new styling theme based on Ag-Grid which will also be customizable via CSS/SASS variables
5. also to help with step 4, and to be more modern, I'm adding a set of slick icons (SVG) that will also be customizable via CSS/SASS
   • I plan to remove all images and replace them with these new SVG icons which is much smaller and more modern
6. I use esbuild for the JS builds which is extremely fast and also has TypeScript built-in support, I also use SASS to build scss to css and finally I use BrowserSync to automatically reload browser whenever I do any of these:
   • change JS/TS (it will rebuild with esbuild, all 3 types (iife, cjs, esm) and reload browser)
   • change SASS file (it will rebuild into .css file and reload browser)
   • change HTML file (it will also reload browser)
   • Note: using Browser-Sync is allowing me to keep all examples that we already have without having to build a new SPA (single page app), the examples will just need to be updated to the new scripts/styles folder locations and that's it
7. TypeScript will come next but it will require us to change the JS source script files location from the root into a new src/ folder, so I didn't start this yet because I'm waiting to see if any issues arise from v4.0 release that I need to fetch. This should be quite easy to use since esbuild as built-in support for TS files, the longest part will be to add interfaces for all of methods and options of SlickGrid
8. also thinking of adding Prettier to have clean code and avoid linting issues

So the future is looking bright, I'm working on steps 1 to 6 and 7 will come later. The next major promises to include a lot of nice things and be a lot more modern. I'll push what I have in a few days or a week, so you'll be able to try it yourself, it requires a few dev dependencies to be installed (npm install).... and wow I gotta say that I love the new theme, it's gorgeous and I'm loving it 🍦

in summary, I'm done with testing POC stuff and everything that I wasn't sure if it was going to work or not, well it turns out that I got it all working and it's quite awesome, there's a lot of new concept coming and that will totally modernize SlickGrid...

EDIT

I'm actually having issues with what esbuild is bundling, it includes everything that is imported, so it's actually bundling the same functions multiple times. So I'm not sure yet how I will produce ES6 bundle yet. For example some core methods are used in SlickGrid and SlickDataView and when I use import and I bundle with esbuild, it produces duplicate copies of these methods in both files. Having Slick on the window object is really the best so far to dynamically add plugins and others... So I'm not exactly sure how to proceed with this, I think the only possible approach might be to use dynamic imports like await import('slick.core.js') and that would fix standalone (window.Slick) but that would make things like DataView as async which is a downside and the other downside is that it's not tree shakable, hmm...well I don't know anymore

EDIT 2
It might be doable by writing a custom esbuild plugin, I think that I got a custom plugin kinda working but it's not very elegant and requires extra lines, I posted a Stack Overflow question here, so hopeful someone else can provide a more elegant solution than mine. Nonetheless, I think it's possible to get it working for both ESM and standalone scripts (iife). More to come...

EDIT 3
It's happening!!! I got both builds working (iife, esm) and I was able to remove unused code depending on the build format by taking advantage of esbuild plugin API (for example standalone iife uses Slick on the window object, however ESM does not use the Slick object but prefers import). This concept was very important to be handled correctly since we don't want to increase our build size by adding code that don't belong to the chosen build format, we need to make sure to only bundle what is being used by the build format type (i.e. Slick on window object for iife build only).

So the end result will be that the standalone <script> will still produce separate files (same as it ever was, except the new dist/ location), however ESM build will only produce a single bundled index.js file which is tree shakeable, so if a user wants to create a grid without any plugins then they user will only import what he uses with import and the rest will be removed/dropped by the tree shaking process.

Also another great thing coming up, I'm working on a new modern styling theme (similar to Ag-Grid) and all images are being dropped and going away, these will be replaced with SVG icons to go along with the new theme and it's beautiful and small :)