For the old version support. Why not do some compile time #ifdef SUPPORT_ES3? That way library writers can support it and if the user doesn't need it they can disable it at compile time and all the legacy code will be removed

▲

sgbeal 3 hours ago | parent | next [-]

> Why not do some compile time #ifdef SUPPORT_ES3?

Rather unfortunately, JS has no native precompiler. For the SQLite project we wrote our own preprocessor to deal with precisely that type of thing (not _specifically_ that thing, but filtering code based on, e.g., whether it's vanilla, ESM, or "bunlder-friendly" (which can't use dynamically-generated strings because of castrated tooling)).

▲

Griffinsauce 7 hours ago | parent | prev | next [-]

Two problems: - people would need to know how to effectively include dependencies in a way that allows them to be tree shaken, that's a fragile setup - polyfills often have quirks and extra behaviours (eg. the extra functions on early promise libraries come to mind ) that they start relying on, making the switch to build-in not so easy

Also, how is this going to look over time with multiple ES versions?

	▲	sgbeal 3 hours ago \| parent [-]
		> people would need to know how to effectively include dependencies in a way that allows them to be tree shaken Is the need for tree-shaking not 100% a side-effect of dependency-mania? Does it not completely disappear once one has ones dependencies reduced to their absolute minimum? Maybe i'm misunderstanding what tree-shaking is really for.

▲

ascorbic 7 hours ago | parent | prev [-]

It'll still install the dependencies, which is what this is about