feat!: major folder restructuring with esbuild to support iife, cjs and esm and TypeScript

[ghiscoding]

• add esbuild as our main bundler, with esbuild we now have 3 different builds in the dist folder
  • iife which is the same as the start of SlickGrid years ago, the only difference will be the located under dist/browser
  • cjs for CommonJS build for NodeJS legacy loading using require(...), located under dist/cjs
  • esm for ES6/ESM support which will give us Tree Shaking support (located under dist/esm)

I did a lot of research to make sure that we get the smallest possible builds for each build format types, for example I didn't want to have code that isn't used by the iife format but required for esm and vice versa (i.e. import are used by esm but not used at all in iife). It took me a while to find the best approach, I even asked on SO with this question: esbuild hybrid plugin to bundle multiple files iife and single esm bundle and opened an issue on esbuild as well. Eventually made it all work with the smallest build sizes for all build types, woohoo 🚀

Starting with the iife build (located under the dist/browser folder) we will still build individual files and we are still adding everything on the Slick object on window (i.e. Slick.Grid or window.Slick.Grid)

On the other hand, the cjs and esm are both producing a single index.js bundle and the esm will provide us with Tree Shaking support. As opposed to iffe though, there will not be any Slick object produced, the user will have to import (or require) everything, for example with esm we would do import { SlickGrid } from 'slickgrid'; and that is the common approach for ES6 syntax

Installation

1. npm install to install all new dev dependencies (esbuild and others...)
2. npm run dev for development using Browser-Sync and build for dev mode
   • this will open a new browser page, the index.html was updated will all the Example links (which contains the same as the Examples Wiki)
   • also note that the ESM examples will only work through this dev mode, however the non-iife examples can still be run without the http server as long you had originally ran a build

Then finally, and hopefully, be amazed by the new Alpine Theme look and feel... Beautiful, isn't it? 🐰

Note ESM examples will only work when running the http server (with npm run dev), on the other hand the regular examples can still be run independently by opening file in the browser but you will be required to first run a build, so... technically speaking it's mostly easier to just run npm run dev for everything (this brings a watch mode which is a lot more useful).

Info

The new structure will use a lot more new tools for development like:

• esbuild to build and bundle, it takes anything from JavaScript and even TypeScript and produces JS build
• chokidar to watch for file changes (.ts, .js, .css, .scss and .html) and run appropriate process (i.e.: .scss will run a SASS build, .ts would run an esbuild, ...)
• browser-sync to run an http server & also watch for any html file change, if anything changes the browser-sync will automatically reload the opened web page (also reloads on any file change).

The use of Browser-Sync is awesome because we no longer need to refresh the page, whenever a file changes (js, css or html), the watch mode will simply reload the page by itself, awesome! The use of Chokidar in combo with Browser-Sync is also great since it will also rebuild SASS to CSS and reload the page as well if anything changes.

This PR branch was created about 2 months ago so it contains a lot of old commits (including the previous major version) but I feel now is a good time to merge it into a new next branch and get feedback from others. I say this because at this point, I feel like the folder structure is pretty much what I want it to become at the end of this exercise.

Upcoming TypeScript

Like I mentioned earlier, we can use esbuild since it accepts TypeScript (and JavaScript) and it's super fast to build. When we run our final production build, we will also use TypeScript to create all the Types (d.ts) files and source maps.

I already converted 1 of the plugin, it is the smallest one which is good to start with and that is the SlickAutoTooltips and it is also part of this PR. So yes, TypeScript is coming...🤖

This next major version will eventually close some old issues as well

• updating to node ES6 #41 -- one of SlickGrid's oldest issue requesting ES6 support
• Possibility of replacing the images directory with Data URIs #255 -- add a small subset of SVGs in pure CSS and delete all images
  • why use SVG instead of Data URI? Read this article: Probably Don’t Base64 SVG
• Bootstrap or styles #533 -- we have a new styling theme: Alpine Theme
• slickGrid column resizing not worked Properly in RTL  #446 -- RTL support simply by using Flex container (in the new theme)
• Grid content disappear when dragging scrollbar on big data sets #219 -- scrolling on large dataset shows blank screen

Conclusion

So in conclusion, I encourage anyone to give it a try. Also note that this PR will be merged on the next branch and a few more PRs will follow (like TypeScript migrations). At this point the folder structure is not expected to change much more than what is in this PR, however all the .js will be renamed as .ts files. Please note that all images were deleted, it's all SVGs now and in pure CSS, so we can even easily colorize them, SVGs are not just used by the new Alpine Theme but also referenced by the old SlickGrid theme which I updated as well in order to get rid of images. This new Alpine Theme was based and inspired from Ag-Grid.

To see the new folder structure, you can take a look at the feat/esbuild branch directly

EDIT

I managed to migrate slick.grid and even slick.dataview to TypeScript (that took a week to accomplish) and that was the biggest challenge, so the rest of the files should be easy (all Controls and Plugins). There's no more obstacle for the move to TypeScript :)

[ghiscoding]

@6pac I'm going to merge this PR to next branch since it's already starting to be quite large. All the core files were converted to TypeScript, the next step will be to convert all Controls & Plugins in future PRs into the next branch.

This way you can start testing and toying with the new structure and you could start creating PR against it (on the next branch), for example your open PR #805