DataTables 2.0 removes legacy UMD auto‑registration: impact on $.fn.dataTable
0 reputation · 30 Jun 2022, 03:18 UTC
0 reputation · 30 Jun 2022, 03:18 UTC
Projects that load DataTables via a plain <script> tag and rely on the historic $.fn.dataTable plugin face a breaking change in version 2.0 because the primary distribution is now an ES module build that does not automatically patch jQuery.
The documentation introduces a window.DataTable global for no‑bundler use, but it is unclear whether the project will continue to provide a standalone UMD file that restores the $.fn.dataTable auto‑registration for legacy workflows.
Developers need to know if they must adapt existing code to the class‑based new DataTable() constructor or can continue using the jQuery‑style API without a bundler.
Will a dedicated UMD bundle be published, is the window.DataTable global sufficient, and what version timeline applies?
34275 reputation · 30 Jun 2022, 08:57 UTC
No dedicated UMD bundle that restores automatic $.fn.dataTable registration is confirmed for DataTables 2.0. The primary 2.0 distribution is an ES module; loading it with a plain <script> tag exposes window.DataTable but does not patch jQuery by default. If your zero-bundler project depends on $.fn.dataTable, the safe path is to remain on the 1.13.x line or explicitly wire up the jQuery integration yourself.
Confirmed in the 2.0 architecture: the core build is an ES module, the native API is the class constructor new DataTable(table, options), and the no-bundler entry point is the window.DataTable global. What is not confirmed is whether the maintainers will publish a standalone UMD artifact that re-enables legacy auto-registration, or whether a separate jQuery integration build will be shipped for plain-script consumers. No public version timeline has been announced for either option.
window.DataTable is sufficient if you are willing to drop jQuery-style calls and use the class API directly. It is not a drop-in replacement for code that invokes $(table).DataTable() or relies on jQuery method chaining. Manually assigning $.fn.dataTable from window.DataTable may work for simple tables, but it can break older extensions because 2.0 extension compatibility is version-specific and the legacy plugin surface included more than a constructor alias.
Run these checks in the browser console after loading your chosen 2.0 script:
typeof window.DataTable; // "function" if the class is present
typeof jQuery.fn.dataTable; // "undefined" if auto-registration is absentThen inspect the package entry points in node_modules/datatables.net/package.json (or the downloaded archive) to see whether a jQuery-specific build is listed. Finally, test both APIs against your actual table markup:
new DataTable(document.querySelector('#myTable'));
// vs.
jQuery('#myTable').DataTable();Which DataTables extensions (for example Editor or Buttons) and which exact 2.0 build file are you loading? Extension compatibility determines whether a manual jQuery bridge is safe or whether you should pin to 1.13.x until the maintainers clarify the UMD roadmap.
Use comments to ask for clarification. Post a solution as an answer.
34,275 reputation · 30 Jun 2022, 10:44 UTC
DataTables 2.0 still ships a UMD build (dist/datatables.umd.js) in the npm package, but it does not automatically patch $.fn.dataTable. To keep the legacy jQuery‑style API you must load that UMD file and, after jQuery is present, assign $.fn.dataTable = DataTable; (where DataTable is the export from the UMD). If you prefer the class‑based approach, the global window.DataTable works without jQuery, and you can initialise tables via new DataTable('#example').