GeezerVison

Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

❌ DanielRosenwasser sign now
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

Newest updates give a better error message when you have TLA in a CJS module.

Most recent changes remove the error message for importing a JSON module under Node16 and NodeNext.

A decent amount of stuff seems to already use/support Node 12.

https://cs.github.com/?scopeName=All+repos&scope=&q=%22%5C%22module%5C%22%3A+%5C%22node12%5C%22%22+language%3A%22JSON+with+Comments%22

Should we keep it undocumented and provide an error when using it, but continue supporting it otherwise?

I mean, as I said back in the issue, I'm all for having newer stable versions to match the node versions people wanna target, alongside the existing versions we support, in the same way we build out a new esXXXX target every year (potentially if only to match up that node version to the correct esXXXX target automatically). If we only do even-numbered (and thus LTS) node versions, we should only need to add one every year or so as well.

Sounds like we have fairly good reasons to have both node16 and node18, in addition to 12, since 16 has all those fun es2022 features and 18 has stablized tla and JSON imports, while 12 already has some use.

Spoke with Anders Hejlsberg (@ahejlsberg) and Andrew Branch (@andrewbranch) on this. We could just say Node18 as the initial minimum target which would simplify a bit for us; however, like you've mentioned, Node 18 can get more and it's not yet the active LTS. So let's start with Node 16 and if we see anything that diverges, we can add a Node18 target down the line.

Consensus was on not providing a workaround for nightly-only users. Either you have nightly TS in a lockfile or you've signed yourself up to staying up-to-date.

Just remember that any perceived simplicity from initially supporting fewer explicit node versions is very likely a short-lived pipe dream at best - we will have to add more, the same way we add esXXXX targets every year. The kind of big-bang module system update that happened with the esm transition is not how node usually does development, usually you get more minor changes each release, as we can already see between 12, 14, 16, and 18. (And the only reason we didn't see a need to update the commonjs resolver for so long is because all those minor resolver changes were being banked up for the node 12 esm drop - even the cjs ones.) If the issue is the perceived complexity or messaging of many targets, that can is only being kicked, not fundamentally solved.

IMO, a longer term more complete solution would be following in the footsteps of... pretty much every js transforming tool in the js community (eg, babel via preset-env, rollup's target argument), and taking arbitrary engine versions/ranges and mapping them automatically to our internal feature flags (eg, es target, module (resolution), and emit features). That would be more predictable into the future, imo. Messaging is probably simpler: 'specify all desired target runtimes, eg target: node18.1.1,chrome101,firefox102,... and we'll figure out the rest.' where you can even specify future versions we don't explicitly handle yet and we can assume those map to next variants of our various features until we add explicit mappings.