Continuation of discussion from https://github.com/eslint/eslint/issues/15453

Discussion on ESM-only projects.md

I understand your argument about force, and although I very much sympathize with the general tendency to seek to do things without what one could in a sense call "force", I think there are a few factors which are obscuring matters here.

For one, I think we have to be careful that we are not engaging in a fallacy of equivocation. While it is especially disconcerting to see "force" being used ot justify even well-intended behaviors, when understood as compulsion under threat of violence or imprisonment by the state, obviously we are not talking about anything remotely similar in degree here (assuming all would even agree that this is indeed a form of compulsion at all).

So saying "it's always wrong to force things on people" might be seen as gaining credence by attacking the strawman of a supposed claim justifying physical compulsion. This brings me to my second point which is about the polemical-sounding nature of engagement with such a fallacy.

Polemicists use ambiguous language such as this to obscure matters in the course of seeking to win temporary support for their arguments, but their doing so also obscures a detached search for truth to really look dispassionately together at what is at hand without complicating things with language that may be interpreted in a way that evokes more moral outrage than is relevant.

In this vein, to highlight the polemical impression such an argument gives from the other side, suppose I were to have used similarly equivocal language to suggest that you were in fact "forcing" others. I am not supporting this kind of polemical language, because I don't find such strong terms helpful, but it may incidentally also highlight the point about polemicism as well as the logical points about ESM breakage that I wish to make.

A polemicist might claim that you were actually the one being forceful on insisting on your viewpoint or that you were seeking to "force" the project to maintain backward compatibility. Again, this would be unfair, given the strong connotations of physical pressure of "force", but I expect you can admit, you are indeed seeking to exert some "force" in a weaker sense. True, you are not holding a gun to our head, but neither are developers of ESM-only projects. ESM-only projects are simply not doing work that you want them to continue doing.

While you might respond that there is some kind of social contract calling on us to help others, so this "burden" on us was merited, even setting aside your categorical rejection of "force" in pressuring us, still, why are we not part of the social contract too? Why are the needs of the many of us who don't want to be stuck with extra procedures not relevant? Is our free labor here a kind of slavery (yes, more potentially polemical language) whereby we are compelled to do your bidding rather than our own? This is not to mention some of us not wanting to prolong the community having no incentive to get around to supporting ESM--what about that social contract (to "think of the children" if I may further the polemicism)? If there were a technology that could speed up the Internet by 100 times, and yet it required 1 hour of pre-announced internet down-time, "forcing" users of the internet to suffer for the benefits of a new innovation, would you not be at least open to considering the idea? What if it were 1000 times the speed and only five minutes of down-time. Surely, you can see there is a spectrum here.

But my main goal is to set the polemical discussions of "force" aside, and instead get back to suggest in non-charged language that one might argue that you are putting the burden you wish to seek to avoid instead on ESM-only-favoring developers and future generations due to some absolute, unyielding value being assigned to backward compatibility.

Now backward compatibility is an understandably admirable standard to strive for, especially in fields like the web where there is such a vast prior output (and by many not so technical users) that one would not wish to lose access to it).

But another factor I would like to argue, unrelated to polemics, is that this form of "backward compatibility" is akin to the type of breakage we see as in "breaking the web". This can hardly be compared in degree to purposely creating a browser which no longer is capable of displaying old websites. We're talking about competent developers having the inconvenience of needing to tweak their code (and who regularly need to make tweaks anyways, e.g., to avoid vulnerabilities or support their userbase), and yes, perhaps face some suffering as the dependency chain is fixed or alternatives are found. But the changes required are not extreme in degree, even if it is admittedly of no small consequence either. The impossibility of contacting all website owners to "fix" their code is not the same as contacting all non-ESM projects to retool their support for ESM. In addition, most ESM projects today can continue using non-ESM code, so the burden is really only on non-ESM or polyglot dependees rather than dependents. As developers start getting used to creating ESM code, they will make ESM-friendly or polyglot versions--because they wish to support the community, and the problem can be assisted from the ground up.

Because dynamic import exists, ESM also requires linting to preserve static analysis.

Gotcha.

The utopia you want simply can’t ever happen. Browsers have a DOM, node/deno can make network requests and talk to a filesystem and have env vars etc. environments are different, and without a build process, there’s a huge amount of code that simply isn’t universal.

You always have to know what environment(s) code is written for, and you only sometimes can transform it to work in other ones.

Node has JSDom, browsers can be empowered through the File Access API to talk to the file system, use node-fetch or file-fetch, reuse URLSearchParams, etc. I live almost every day in other regards in such a very comfortable utopia with various projects that are environment-independent and can leverage libraries that work in different environments. That's one of the biggest draws of JavaScript to my taste and to others I know as well. With linting especially--and I wasn't speaking against linting earlier, merely that it is ideal not to have to depend on it--and for ESM or CJS one doesn't need to depend on linting just to use it even if certain errors may get through without accurate use for a given purpose as is expected--one can prevent use of globals to ensure that any environment-specific code goes into its own entry file.

And based on what I've encountered, many projects are open to becoming out-of-the-box environment-independent, but their author just happened to write it in CJS...

CJS that happens not to use environment-specific features is precisely as environment-independent as ESM that happens not to, since both are well-understood input formats.

Since import maps aren't a standard, there remains no way to have node code with nonzero dependencies work in a browser without a build tool. If a build tool is required, ESM and CJS can both be identically consumed.

In other words, the only time I think you have a reasonable argument for environment-independent usage is when you have code that meets all these requirements:

1. exists in a single file
2. does not import or require anything
3. does not use any environment-specific features (filesystem, network, user input, DOM)
4. does not use any APIs outside of the main language specification, which excludes Intl - i can make an exception for console.log and setTimeout, of course, despite these not being in the language itself, since these are so universal

The amount of packages that qualify for this are vanishingly small.

Though it isn't as pretty as with import maps, one can target node_modules paths directly (for a browser script tag). This works fine for the purposes of a demo when, as is the general situation in which one wishes to run a demo, it is run at the top level of an application and the relative directory structure within node_modules can therefore be deterministically known.

And since projects can make polyglot code with environment-specific code either by inline checks or, as per my preference, separate entry files (e.g., where the Node version supplies a JSDom object as the document object), one can simply import the relevant entry file, so your condition no. 3 is not required. Similarly with condition no. 4. Mitigating the challenges with this are the plethora of libraries previously mentioned like file-fetch, node-fetch, indexeddbshim, etc. which allow for reuse of the same standard APIs across browser and Node as well as browser globals implemented by Node (e.g., URL, URLSearchParams).

The demo application can thus load external third party distribution files out of node_modules (e.g., let's say a jquery distribution and plugins) and any self-contained code within the project it is demoing. The main JavaScript library being imported into the demo should not itself be hard-coding node_modules or it may have problems when imported by other packages, but the HTML file may do so. So your item no. 2 is relevant but only if the library being demoed has external dependencies. In such cases, it is often a large library which needs minification to be practical as a demo anyways which is not my use case. (I'm talking about demoing nicely, modular, single-purpose atomic packages.) But regardless, the file being imported can itself safely include imports of relative paths (e.g., if importing an ESM entry file in the source code where again there are no external dependencies), so condition 1 is not relevant.

So the only relevant condition under this frequent use case is condition 2 (if condition 2 is understood as not importing external dependencies but allowing for project-local relative imports). And hopefully import maps will help even with this condition.

In order to target node_modules, you either need to serve the whole thing (a massive security risk) or run a build process to selectively serve only the files you need.

If you have separate entry files, then you also still need a build process to locate them (outside of node). Note as well that JSDOM tries, but is nowhere near sufficient or equivalent to the actual DOM.

As for node-fetch, the spec for fetch means that a non-browser implementation can never be standards-compliant, as node-fetch is also not.

I think my conditions continue to all apply.

In order to target node_modules, you either need to serve the whole thing (a massive security risk) or run a build process to selectively serve only the files you need.

Not if you're running the demo locally. Again, this is intended especially for rapid development and working on smaller projects.

If you have separate entry files, then you also still need a build process to locate them (outside of node).

Or you can just discover them browsing through the file system or in the project docs.

Note as well that JSDOM tries, but is nowhere near sufficient or equivalent to the actual DOM.

True, but still useful for SSR and such.

As for node-fetch, the spec for fetch means that a non-browser implementation can never be standards-compliant, as node-fetch is also not.

I'm not sure in what regard you're speaking, but even if tweaks are necessary, one can often use an entire API unmodified besides the entry point.

I'm not sure why demos matter; that's not the important audience for software. We should be optimizing for actual production usage, not one-off weekend projects.

I'm not sure why demos matter; that's not the important audience for software. We should be optimizing for actual production usage, not one-off weekend projects.

Many libraries are just developer tools. They don't need a splashy public page. One can smart small, and turn it into a build routine later if desired. I feel we should also be tolerant of different purposes and levels of users in their manner of producing their work.

I personally may add a build routine later solely for copying node_modules files into the repo for use by the likes of GitHub Pages. But my project's own ESM code still doesn't have to go through a build routine in such cases (unless the main library imports other dependencies).