Thanks for the report. FWIW, you wouldn't ever need:

import jQuery from './node_modules/jquery/dist/jquery-esm.js';

In fact, it could be quite fragile as npm dependencies may be hoisted. This is enough if we generate the jquery-esm.js file:

import jQuery from 'jquery/dist/jquery-esm.js';

While yes, there is that fragility, it can still be useful. For example, I like to use it in repo demos and tests where it is just meant for development and can safely be used as a direct dependency. It should also be safe for applications which are known to be the root.

With such paths, there is no need for bundling as one needs when pointing to jquery/dist/jquery-esm.js (at least until import maps may support such mapping of node_modules).

Ah, right, I was thinking about a bundler use case and you mean native browser import, got it. If there's no need for bundling then we could just point to src/jquery.js as that's our main source file. However, that would load quite a lot of files so while it's fine for development, for production you'd usually want at least partial bundling. HTTP/2 may solve this issue partially but it's probably still slower than loading a few bigger files.

Regarding bundling, Rollup allows "esm" as a format for distribution, so one could just add and inform users in the docs of the presence of such a pre-bundled dist file, while pointing module to src/jquery.js for the sake of bundlers (assuming you have no dependencies and your files all have extensions, as both appear to be the case).

I don't find any file named jquery/dist/jquery-esm.js in the project, how to find / build it please?

@florealcab : It doesn't exist at this point. That's what my proposal is for. Currently, you have to build it yourself.

@brettz9 ok, is it possible for you to say me how can I do that?

You need to use a bundler like Rollup (or parcel) or Webpack. The configuration depends on how jQuery has set things up internally. Though I haven't done it with jQuery myself, with jQuery not having external dependencies, Rollup will probably work for you, and it is rather easy to use: https://rollupjs.org/ though you'll need @rollup/plugin-node-resolve at least.

jQuery already has a build process based on Rollup defined in https://github.com/jquery/jquery/blob/master/build/tasks/build.js. For now it only generates a regular script file & its minified version; this could be enhanced to generate an ESM version as well.

One thing to consider is what files we'd like to generate & where to put them. We already generate a regular & minified file for the full build & for the Slim build - those are 4 files. All of them are then uploaded to our own CDN but also to 3rd party CDNs like the Google or Microsoft ones. Would the ESM file be uploaded to them all? Do we also need an ESM slim file? We need to be careful here.

@mgol generally the ESM version would only be used by bundlers right? It might be a good start to simply only have the module field in package json and in the npm module but not add this to CDNs

If people end up making use of this those might be good steps to take in the future?

If you are on board with this approach, I would be happy to give ESM a shot.

I don't use nodejs in my project, but I use ESM version for my dependencies. So a packaged version of Jquery should be useful for me (available in the zip file along with script version of jquery) :)

@florealcab to confirm you want an ESM bundled version in the zip? or just the current CJS works for you?

@mgol generally the ESM version would only be used by bundlers right?

Not only. Node.js has experimental ESM support, docs at https://nodejs.org/api/esm.html; it'd be good to work good with that. I expect bundlers to also start supporting the exports field, e.g. see this Webpack issue: webpack/webpack#9509. So there are some questions on what's the best approach right now when so much is happening in this area.

We're not in a hurry here: jQuery 4.0 won't be out for at least a few more months so we have this time to think about the best approach.

@mgol for sure. I should have said that CDN's would not have much use for ESM versions and it would only be those people requiring via node or a bundler would care about an ESM bundle.

@roopakv : While per @mgol 's comment, jquery may have to weigh the costs in doing so, ESM distributions are not only for Node and bundlers. Browser demos which which to avoid polluting HTML with dependencies, keeping their code simple without build steps and preserving modularity can use it.

(While this is less of an issue for jquery, unless perhaps a Deno equivalent to jsdom were being used, ESM CDN distributions can also be useful for Deno (which does not use a packaging system like Node but does allow targeting modules through URLs).)

I second the usefulness of ESM versions for the browser, I often like to develop small projects without using npm or a bundler, I just grab the bundled ESM version from a CDN like jsdelivr.

I second @SeanBannister, it would be great to have jQuery ESM Browser like Vue do it. Thx !

I've updated to suggest that now that native ESM has come to Node (and the LTS versions all support it), the choice of exports (with import and require) ought to be ideal choices. And bundlers like Rollup with its plugins are already capable of using this information.

jQuery seems to be the only global I need in my (no-bundler-used-or-needed) demos these days...

@brettz9 This past comment of mine in this thread is still relevant: #4592 (comment). In particular, its second section. If we want to generate an ESM file, we'd probably also need the Slim version so that there's no discrepancy between a regular script version and an ESM one. If you (or anyone else) could post a complete proposal on what to put in package.json to achieve the goals here, that'd certainly help in reaching the end goal.

Regarding a slim file, I think having the slim version as ESM would be helpful too, yes. With modularity and importing, one is given the freedom not only to not need to manage or follow the dependency chain in adding script tags, but to choose only what one needs. To me, it is like pre-built binaries--a good project will offer a good range of choices.

Regarding what is needed from exports, I'm afraid I am rather overextended to delve deeply into the project to offer a complete proposal suited to your specific requirements, I can at least summarize what one will need to implement in this manner (or help with answering questions on the process if that may be helpful):

1. "type": "module" in package.json
2. Any files that must remain as CommonJS (CJS), e.g., .eslintrc for now, should be changed to use that extension (.eslintrc.cjs), including distribution files--unless you needed to distribute ".js" for older browsers which might not support detecting JavaScript purely by extension, in which case, the repo could treat "js" as CJS by default and instead have all ESM files, including distribution ones, use ".mjs"). With Node, it must be one way or the other.
3. For exports, add at least import and export (see https://nodejs.org/api/packages.html#packages_conditional_exports ), pointing with a relative path (and unlike main, it must use "./" at the beginning) to the ESM and UMD (or other) distributions. Any inner JavaScript paths that consumers might wish to access should be exposed here (whether explicitly or by wildcard; see https://nodejs.org/api/packages.html#packages_package_entry_points ) since otherwise, the adding of exports encapsulates the package contents such that newer Node versions cannot accessing non-whitelisted files.

Hope that gives something to go by.

prolly missing some risk like hoisting or something...
but looks like if you just append
export default jQuery;

to the bottom of the dist/jquery.js file (and call it dist/jquery.esm.js or whatever)
then that works in browsers, in JS using type="module" script tags and doing something like:
import $ from './node_modules/jquery/dist/jquery.esm.js';

prolly missing some risk like hoisting or something...
but looks like if you just append
export default jQuery;

to the bottom of the dist/jquery.js file (and call it dist/jquery.esm.js or whatever)

While adding such a line does allow a named import to work, it doesn't help with the main draw of using (named) modules--avoiding globals and reducing the chance for global conflict. The jQuery file would still set jQuery and $.

true! though my main goal is to continue to use jQuery w/ projects that are now entirely ESM / import :)

certainly the window.$ and window.jQuery lines could be erased in the .esm.js file, too, while there.
(I'd like that, too -- leave it up to the import-er and/or JS writer to decide if they want to send into window globals or not).

Gets tricky w/ other pkgs expecting those globals (eg: jquery-ui, jquery.cookie -- even just-out bootstrap v5 will add the jQuery short/nice methods IFF the global window var is found).

It's apparently not a technical challenge to add the support for modules no less since there is already a Rollup process in place as mentioned in #4592 (comment) (I don't know if that removes noConflict or whether a Node build (or frame) can pass in its own window at runtime, but at least normal browser environments should work).

But you can get it to work for your needs with ESM-only projects already by just doing the following:

 import './node_modules/jquery/dist/jquery.js';

// Then use `jQuery` or `$` below.

If you are using the likes of ESLint which might complain about undeclared glboals, you still would have to do:

/* globals jQuery */
import './node_modules/jquery/dist/jquery.js';

...but this does at least avoid the need to define dependencies out-of-band within HTML, offering the advantages that:

1. If jQuery ends up being dropped by modules no longer needing it, or is not used within one import chain, the importer will not need to load it.
2. The importer doesn't need to be concerned with how to load jQuery for the dependency (and add it to HTML, for example). So long as the dependency has the right import path; the importer need only worry about importing that file.

isn't it possible to add a dist/jquery-esm.js file, being a separate file it wouldn't break backwards compatibility and could be done right now.

Adding the exports field to package.json is a breaking change. Adding more fields to an already existing exports field is not a breaking change. We don’t have exports in package.json yet so any changes will be breaking.

Read more at https://nodejs.org/api/packages.html#package-entry-points

I'm not entire sure since I haven't used this approach yet but I think you can use conditional exports to provide ESM exports without it being a breaking change. This approach allows the support of the old way require() while also providing the new way import :)

 "main": "lib/index.js",
  "exports": {
    "import": "./index.esm.mjs",
    "require": "./lib/index.js"
  },

See this article What does it take to support Node.js ESM?

I've submitted an experimental proposal at #5122. Read the PR description for more details.

If there are any issues with CORS (ex: hard requirement of a web server to run your javascript, very non-jquery) a similar project at https://htmx.org recently discovered a "2 liner" method of allowing both classic <script> and ESM modules (<script type="module">) without breakage:

• https://github.com/bigskysoftware/htmx/pull/1263/files#diff-82fdb840fffe3a9ee5ebe4d4a61ab7c70fe9da315fa1bfc47bfe836471407ccc

May be of interest to the jQuery project.

@gnat I don’t see anything ESM-related in that PR. In order to expose a library as an ECMAScript Module, you need to use the export syntax which is not supported in regular scripts. It’s impossible to handle both in a single file.

Exporting as CommonJS may make it possible to import from a file if you use a bundler that supports it, which is pretty common. But it does nothing to support actual native ESM.

jQuery already exposes itself via AMD, CommonJS & browser globals.

PR: #5255