(done) Roadmap to 9.0 (skipping 6-8)

[ghiscoding]

next major version ideas (WIP)

Note

I will be skipping version 6-8 and jumping straight to v9.0 and that is because all framework wrappers will be moved into here, and since some of these wrappers (Aurelia/Angular-Slickgrid) are already at v8 then the next logical major version will be v9.0. The quick summary is that every framework wrappers will soon be following the exact same versions in the near future, so everything will be in sync which is a lot easier to maintain (releasing everything in 1 go is going to be awesome).

• 1. drop CJS and go with full ESM-only? Yep we'll schedule it for our next major release around Node 18 EOL
  • this would require migrating from Jest to Vitest (ref PR chore: migrate from Jest to Vitest for ESM support #1663)
• 2. change rowTopOffsetRenderType default value from top to transform in next major release
  • ref PR perf: add new rowTopOffsetRenderType grid option to use "transform" #1650
• 3. possibly switch to column hidden property, which we tried in the past via this SlickGrid PR. It could be an issue in ColumnPicker/GridMenu, requires more in depth testing
• 4. drop Node 18 and upgrade dependencies that require Node 20
  • we can actually drop any Node requirement, it's not really needed since we're switching to ESM-Only
• 5. remove internal deep copy of GridOption and allow user to update any options by pointer or reference
  • see this Angular-Slickgrid issue for more context
  • it might not be possible to make it like a pointer ref (and reactive) but we could use onSetOptions to resync (but might fall into infinite loop though)
• 6. rename previous CRUD singular event names to plural names and always return an array
  • onItemAdded, onItemDeleted, onItemUpdated, onItemUpserted
  • ref PR feat(services): pluralize CRUD events (ie: onItemsAdded, ...) #1910
• 7. provide an ESM only PR to un-flatten-tree repo, or fork the project as a last resource (only if future PR of ESM isn't accepted)
• 8. in Angular-Slickgrid, we should probably:
  • switch to Vite builder, https://angular.dev/tools/cli/build-system-migration
  • upgrade ngx-translate, https://ngx-translate.org/getting-started/migration-guide/
  • upgrade to Angular 19 (or 20)
  • migrate from Jest to Vitest using Analog (see Faster testing with Angular and Vitest)
  • align all example numbers with other ports (i.e. Row Detail is 19 in Aurelia/React but is 21 in Angular)
  • should we make RxJS optional? (maybe revisit in the future, this is too new)
  • npm publish needs to be updated since Angular libs require to publish the content of dist/ as the publish root (maybe this SO, see Lerna old issue)
  • will need to ignore TypeScript version in Renovate but only for Angular
  • update testing docs without the need for Vite/CJS hack (see below)
• 9. in Aurelia-Slickgrid, we could:
  • migrate dev from WebPack to ViteJS
  • use Vite preview (instead of servor) to run Cypress tests
  • upgrade i18next to v24 v25 just came out
  • update to latest Aurelia 2 Beta 24
• 10. in Slickgrid-React, we could:
  • upgrade to React 19, see their blog post and upgrade guide
  • major upgrade i18next to v24 and i18next-http-backend to v3 (same for Aurelia-Slickgrid)
  • can we make i18next optional in Slickgrid-React like I've done in Slickgrid-Vue?
    • ref PR feat(react)!: make I18Next totally optional in Slickgrid-React #1897
  • use Vite preview (instead of servor) to run Cypress tests
  • migrate all Examples to functional components & update docs
• 11. in Slickgid-Vue we could:
  • increase peer dep to Vue 3.5
• 12. SortableJS ESM not working well with @types/sortablejs
  • @formkit/drag-and-drop might be a good alternative to SortableJS, won't go with that approach yet, since preliminary trial shows couple of issues (animation not working, event not provided, quite different implementation)
  • actually found how to use the ESM build of Sortable and still have proper Types in PR fix: use SortableJS ESM & drop TS allowSyntheticDefaultImports #1942
• 13. upgrade to new major version of Vanilla-Calendar-Pro v3, see vanilla-calendar3 branch, however it's missing changes for the use of the new .set() method (see comment) (ref PR feat!: upgrade Vanilla-Calendar-Pro to new major v3 #1884)
• 14. possibly use the modern and simpler Clipboard API instead of creating temp textarea to fake a copy
  • assign Ctrl+C to copy single cell (but without ExcelCopyBuffer enabled to avoid overriding each other)
• 15. possibly move node-extend from utils/nodeExtend to a separate npm org for utils, maybe node-extend-esm, the reason being that the official node-extend repo maintainer has no intention of going ESM because they want to support old NodeJS version, as per this node-extend issue and I want to move it outside of the Slickgrid-Universal world so that other users can take advantage of an ESM package (or maybe even myself in projects not requiring SlickGrid)
  • will skip for now, not sure there's really any benefit in doing this external package
• 16. could we try to move some (ie: RowDetail, RxJS), or all, extensions as optional and maybe do something similar to what I've done in Lerna-Lite code which is to use await import(plugin). I'm guessing that ViteJS is potentially doing similar with SASS which doesn't work until you npm install SASS
  • could we auto-enable certain flags when their associated external resources are loaded? (i.e. ExcelExportService => enableExcelExport) (not sure yet since this might be the inverse of step 34 below)
• 17. potentially create a frameworks folder in the workspace and provide optional install for each frameworks in readme via pnpm install --filter
  • will require GitBook in Monorepo changes / use our "...-demos" repos for live demos
  • move vanilla examples into the new demos folder => /demos/vanilla
  • update all frameworks GitBook links
  • add migration also for Slickgrid-Vue
• 18. if frameworks folder is implemented, we could align all ports to 9.x version (because Angular/Aurelia ports are already at 8.x)
  • move vanilla bundle in the frameworks folder won't do since that might break TS build with project refs
  • move all framework wrappers into the frameworks folder
• 19. VSCode debugger should work for all frameworks, might not be working with new Slickgrid-Vue
• 20. add Prettier formatter to the project (it might need multiple config in each framework ports)
• 21. replace whatwg-fetch with native NodeJS fetch, probably requires Node 20.x and higher (requires Node 18.13+)
• 22. possibly rename the default slickgrid theme to remove Bootstrap from its name since it works without BS (see this note)
  • actually it might be better to add a new one since it requires slick-without-bootstrap-min-styling.scss (PR feat: add a Default Theme to avoid expectation of certain Bootstrap stylings #1806)
• 23. add comma , separator on DateTimeIso Formatter to separate date & time (this might break parsing though, need to investigate)
  • ref PR feat: allow providing custom date format via base Date Formatter #1928
• 24. should we use simpler attributes? Which are columnDefinitions => columns and gridOptions => options
  • Angular-Slickgrid (ref PR feat(angular)!: use simpler input attribute names #1898)
  • Aurelia-Slickgrid (ref PR feat(aurelia)!: use simpler input attribute names #1899)
  • Slickgrid-React (ref PR feat(react)!: use simpler input attribute names #1900)
  • Slickgrid-Vue
  • Vanilla (leave as is)
• 25. bump to ES2022 (ref PR chore: bump TS target to ES2022 #1916)
  • we could use .at() or .findLast() instead of .slice() or even arr[arr.length - 1]
  • also remove Set.intersection() polyfill added in rowspan feature (this actually requires ES2024, but we might be able to use ESNext as input)
• 26. upgrade Lerna-Lite to v4
• 27. release new major version of excel-builder-vanilla as ESM-Only & then upgrade it here
• 28. release new major version of multiple-select-vanilla as ESM-Only & then upgrade it here
• 29. move Linting/Formatting into a separate workflow task, same as Lerna-Lite
• 30. create a version5 branch before merging next branch
• 31. create Migration to v9.x Guide
  • also add it to all wrappers and GitBooks
• 32. can we extend ESLint config for each framework wrapper?
  • not needed anymore, the global eslint (from the project root) works perfectly, the only exception is Angular-Slickgrid that has its own eslint config and npm script (in other words, the associated CI workflow for Angular-Slickgrid is a little longer to run, also because it has its own unit tests as well)
  • or maybe like this Lerna commit
• 33. need to update Lerna-Lite version/publish scripts since we now only use bundle but that is only including Slickgrid-Universal packages and doesn't include our new framework wrappers to publish
• 34. update all demo links to code & in docs too
• 35. Angular Vitest debugger isn't working as expected, also wonder if there is a way to add codecov for Angular-Slickgrid?
  • Using Codecov within a monorepo
• 36. remove any deprecated code
• 37. compare build size
  • so far the build size is a bit larger because latest Vanilla-Calendar version size increased because of all its new features
• 38. can we shorten some grid option names?
• 39. remove old unused docs like Editor/Filter with Flatpickr
  • will wait to do this in the next major
• 40. merge recent PRs from master branch into next branch
  • also update latest docs
  • add missing demos readme
• 41. should we get rid of FieldType and only keep strings? (ie: FieldType.dateIso can already be used as 'dateIso')
  • there's also OperatorType enum vs OperatorString
  • FileType.xls | FileType.xlsx | 'xls' | 'xlsx'
  • and possibly many more
  • ref PR feat: deprecate FileType, FieldType, GridStateType enums #1945
• 42. use the new lazyData option that I just added to ms-select
  • ref PR feat(filter): update multiple-select-vanilla with built-in lazy data #1943
  • maybe also take a look at my other new options preFilter and preSort
• 43. possibly merge editorOptions / filterOptions into same prop name libOptions or simply options
  • ref PR feat: deprecate editorOptions, filterOptions & renamed as options #1946
• 44. remove Editor/Filter error throw on missing args, this can simply never happen, so no need for that error
  • ref PR refactor: remove unnecessary Editor/Filter throw on missing args #1953
• 45. upgrade pnpm to v10 and run CI on Node 22
• 46. remove custom tooltip arrow
  • ref PR fix!: remove Arrow pointer from Custom Tooltip #1964
• 47. test in Salesforce

after the release

• update jsGrids website with all my framework wrappers with their updated links

---

Drag-and-drop test code (click to expand)

Test Code

protected setupColumnReorder(): void {
    let columnScrollTimer: number;
    let canDragScroll = false;
    let reorderedIds: Array<string | number> = [];
    const scrollColumnsRight = () => (this._viewportScrollContainerX.scrollLeft += 10);
    const scrollColumnsLeft = () => (this._viewportScrollContainerX.scrollLeft -= 10);

    dragAndDrop({
      parent: document.querySelector('.slick-header-columns')!,
      getValues: () => Array.from(document.querySelectorAll('.slick-header-column')),
      setValues: (newValues) => {
        console.log('newValues', newValues);
        reorderedIds = newValues.map((el: any) => el.dataset!.id);
      },
      config: {
        onDragstart: (e, state) => {
          console.log('Dragging started', e, state);
          canDragScroll = !this.hasFrozenColumns() || getOffset(e.draggedNode.el).left > getOffset(this._viewportScrollContainerX).left;

          if (canDragScroll && state.coordinates.x > this._container.clientWidth) {
            if (!columnScrollTimer) {
              columnScrollTimer = window.setInterval(scrollColumnsRight, 100);
            }
          } else if (canDragScroll && state.coordinates.x < getOffset(this._viewportScrollContainerX).left) {
            if (!columnScrollTimer) {
              columnScrollTimer = window.setInterval(scrollColumnsLeft, 100);
            }
          } else {
            window.clearInterval(columnScrollTimer);
          }
        },
        onDragend: (e) => {
          console.log('Dragging ended', e);
          window.clearInterval(columnScrollTimer);

          if (!this.getEditorLock()?.commitCurrentEdit()) {
            return;
          }

          if (reorderedIds.length) {
            // let reorderedIds = this.sortableSideLeftInstance?.toArray() ?? [];
            // const reorderedIds: Array<string | number> = (e.values ?? []).map((el: any) => el.dataset!.id);
            console.log('reorderedIds', reorderedIds);
            // reorderedIds = reorderedIds.concat(this.sortableSideRightInstance?.toArray() ?? []);

            const reorderedColumns: C[] = [];
            for (let i = 0; i < reorderedIds.length; i++) {
              reorderedColumns.push(this.columns[this.getColumnIndex(reorderedIds[i])]);
            }
            this.setColumns(reorderedColumns);

            this.triggerEvent(this.onColumnsReordered, { impactedColumns: this.columns });
            // e.stopPropagation();
            this.setupColumnResize();
            if (this.activeCellNode) {
              this.setFocus(); // refocus on active cell
            }
          }
        },
        // onSort: (event) => {
        //   console.log('Sorting', event);
        //   return !(event.draggedNode as any).classList.contains(this._options.unorderableColumnCssClass as string);
        // },
        plugins: [animations({ duration: 500 })],
        synthDraggingClass: 'slick-header-column-active',
      },
    });
}

[ghiscoding]

@zewa666 So I'm assuming that since I'm going full ESM-Only, you probably won't need this patch for Angular Testing Library - Vitest CJS instead of ESM loading. The docs will probably need adjustments with the upcoming major release!?

You may experience issues when using Vite + Vitest (e.g via AnalogJS) where Vitest would load the cjs version instead of esm of slickgrid-universal. The reason for this is that nested sub-depdendencies aren't properly analyzed and left up to node's loading mechanism. (see vitest-dev/vitest#4233 for more details).

[zewa666]

correct, finally getting rid of this uglyness 🎉

[ghiscoding]

@zewa666 so I might be closed to be done with the changes, there's number 5 that you were interested but there's a couple of deep copy in both Angular-Slickgrid and SlickGrid and I'm not sure if we can have ref pointers to work (or I just update the attribute with onSetOptions event but I'm afraid of going in infinite loop). There's also number 23 that I might look into, but I'm not sure if I should add more date formats or simply add the comma (ie: "2020-02-02, 14:20:20pm"). if I just add a comma then it might break some parsing, I guess adding new formats might be the best!?

I started to write the migrations in separate Wikis, easier to edit, you can see the Angular-Slickgrid migration to 9.x

[zewa666]

why the need for the comma in the date? was that a custom format required somewhere? cant remember that one

[ghiscoding]

haha no that's just me using it on a work project and I like to use ISO format but with the date+time+am/pm, it starts to be a little long and a comma is often used to separate date & time. I could also use a custom formatter but didn't feel like it 😆

[zewa666]

as for 5, I dont think the effort stands for the percepted benefit. clear documentation should be enough and this simply becomes part of the legacy tbh. In our project we got used to that and since than its no issue at all anylonger

[ghiscoding]

so I was looking again about number 23, now that I'm at work, and my dates are displayed like this 2025-04-14 02:59:17 pm. I was actually surprised that I've added a space for between time and am/pm but this made me think further. What if I go with a different approach, I think it might be better to simply create a base date Formatter that the user can define his own format, like this formatter: Formatters.date, params: { format: 'YYYY-MM-DD' }}, however the column with date type can also be used for date parsing when a type is provided, like type: FieldType.dateEuro, which is used by Sorting/Filtering, so perhaps the params usage is not a bad idea and I could make it usable for both Formatters and Date parsing (input/output)... hmm the format might be different for input/output, so perhaps I should use params: { inputFormat: '...', outputFormat: '...' } or maybe even better is a mix of both
params.inputFormat ?? params.format ?? new Error('could not find any input date format, please provide a format')

I was pretty much thinking out loud when writing this, but I think it makes sense to implement this approach and it would make the library a bit more flexible (because currently if your date isn't available in a date type, then you're a bit out of luck and you would have to parse the date yourself and/or implement your own date sorting/filtering). I could even go further and drop all these date types entirely, but that would probably cause too many breaking changes to the users, so I guess that implementing this new approach and keep current date types for now is probably the best move instead of adding more and more date formats. Feedback welcome...

[zewa666]

I typically range somewhere between absolute non-understanding and insulting people when requesting non-standard date formats, as the existing ones are already a nightmare to handle 😂

but I can see your point. especially the different in/out format as the save might go towards a different system requiring another format

[ghiscoding]

haha yeah I'm totally with you on that one lol, especially the fact that I'm Canadian and the US is our neighbor, their format always felt so strange to me, why do they put the month before day?? I love the ISO format but they often make me change the format to US because that's what they're used to, oh well can't always win lol

Side note, the thing too about parsing, is that sometime the dates saved in the DB is an obscure format that isn't in my list of date type and sometime you can't change that. Luckily, this doesn't happen too often

[ghiscoding]

@zewa666 so another subject I just investigated number 45 above that I just added, I didn't think about that when I created the lib but TS Enums are actually all compiled and taking up space in the transpiled JS bundle (ie: dist/caseType.enum.js). However using string type does not and ChatGPT was helpful with this investigation. For some of them I came up with code like this outputType?: (typeof FieldType)[keyof typeof FieldType] which allow me to use either outputType: FieldType.boolean or outputType: 'boolean' and in some other use case I also created both Operator enum and OperatorString to offer both ways to the end user. I was concerned about string type not allowing TSDocs for intellisense but ChatGPT says that I can also add them, however a small negative side is that I can't add things like @deprecated or @see on individual string types which is fine by me since I would only add such things on the entire type not on individual.

export type FieldType =
  | /** Unknown type */
    'unknown'
  | /** String type */
    'string'

Typically using Enums isn't a big deal when you're not using too many but... But the thing is that I use a lot of Enums (see enums/* and in other packages as well) but replacing them with string types would be a huge breaking change. I could add @deprecated to all these enums and mention it in upcoming migration to advise users to start using 'dateIso' instead of FieldType.dateIso and remove them in yet another major in a year or so....

Any thoughts on the subject? Converting them all back to string types might decreased project build size a bit. I think it might valuable to remove some of these Enums but maybe not al of them (FieldType is definitely one that I'd like to remove eventually, I supported string literal type since a couple years already, some users probably use only that)

EDIT

I was curious to see how much difference this makes and I open the slickgrid vanilla bundle zip (a minified+zip bundle used for Salesforce) and I just deleted the FieldType object that is being created when we use TS Enums and I almost saved 1Kb and that's just 1 Enum, imagine if I remove a big bunch of them, I could lower the bundle size by a few Kb I think. Note that this isn't gzip but it is minified code and below is what I get (right side is before, left side is after I remove FieldType highlighted code behind), the size on disk didn't budge though

[zewa666]

phew I think I'm the wrong person to ask it since I'm totally biased. the apps where I use slickgrid are internal hence I dont care about a few kb more or less tbh. the previous solution I'm replacing didnt support paginations and lazy loads so it loaded a couple of mb on the start 😅

that said, enums are somewhat seen as an antipattern, exactly due to the code gen and partial type unsafety. one way to work around that, if you're not reverse looking up values labels from enum values is to use const enums as these inline the value and emit no code

https://medium.com/@ta234567801/understanding-const-enums-in-typescrip-a2725649697a

Imo i'd do the following. new features should not use enums anymore. each time you touch a code base you add deprecation notices to enums. once enough are collected do a properly addressed breaking change

[ghiscoding]

well the good thing is that I was already using const enums without knowing the benefit, simply because I always export my interface/types/enums as export const enum, so I felt on the good side without knowing it haha.

I also use grids mostly in projects for the business that don't care much about build size too, but still... if I can decrease the bundle size without impacting the lib usage, then I don't see why I wouldn't work on that ;) My main goals are decreasing bundle size if possible and keep intellisense, if that later gets drop and usability is worst then I refuse to do the change, but in this case and from what is shown above, I can do both so... :)

Thanks for the article, I wasn't aware of it, even if I already used this by accident hehe. So I will do like you suggested and start deprecating stuff little by little and stop using enums for future stuff. Cheers and happy Monday

[ghiscoding]

@zewa666 @jr01 hey guys, so I'm pretty much done with all I wanted to do before releasing the next major v9.0. You can take a look at the Migration v9 for Angular-Slickgrid. Let me know if I missed anything or if there's something you wanted to discuss before I go ahead with the release (probably next weekend)

[zewa666]

sounds and looks fantastic. looking forward to it and will plan a new slot for the next iteration to update our main app.

I'm especially looking forward to being able to contribute a single PR for both Core and Ng Wrapper at the same time in future 🎉

[ghiscoding]

and I'm especially looking forward to push a new release for all frameworks & universal in 1 single action 🚀

Side note, I managed to keep Angular-Slickgrid unit tests (apart from vanilla, that is the only other framework that I kept test coverage) using Analog and also managed to update Codecov to merge both test reports, it now shows coverage for both even though they are separate processes, it's pretty cool :)

[jr01]

@ghiscoding Nice work! Looking forward to migrating!