Closed theoludwig closed 4 days ago
I'm not so sure on this one. I would maybe push this one major version forward.
I'm not so sure on this one. I would maybe push this one major version forward.
Could you elaborate a little bit more? Do you think it is too early ? What are the downsides to do this change ?
The downsides is that we, in addition to other changes, need to change how we import this module in all the projects that uses this module + ideally also convert those to ESM then.
As ESM can easily import CommonJS in Node I think it would be better to start converting the individual users to ESM before converting this module.
Also: I would ideally have the ESM change in a version where there are no other breaking changes as it's enough of a breaking change to migrate to, also having to deal with other breaking changes at the same time becomes a bit too much, so I would rather avoid it if possible :)
start converting the individual users to ESM before converting this module
Sounds good to me! :+1: We will do it for v16, so we can slowly migrate the whole organization to ESM.
pkg-conf was also converted to ESM recently - it's much smaller in size now guess we don't have much of a choise to start using ESM if we want to update any of our dependencies now.
@jimmywarting We can use many ESM modules in CJS by importing them like await import('pkg-conf')
, so we can hold out a while longer
oh great, not many package have the luxury of using lazy import
@jimmywarting We can use many ESM modules in CJS by importing them like
await import('pkg-conf')
, so we can hold out a while longer
Currently, there are #238, #247 and #262 PRs to fix, if it is possible.
It is failing because the packages have been converted to ESM, would appreciate a PR if it is possible to fix with dynamic import (await import
). @voxpelli
all doe i would have prefer if it got switched to ESM-only, but understand if you are not ready yet to go full ESM-only
if you missed it node-fetch@3 (the largest http lib) just went ESM-only :P
all doe i would have prefer if it got switched to ESM-only, but understand if you are not ready yet to go full ESM-only
if you missed it node-fetch@3 (the largest http lib) just went ESM-only :P
I agree I would love to switch to ESM-only, but there are so many things breaking with this change that we still need to wait a little bit before doing that.
And it would offer a smoother transition to migrate to ESM only for packages like standard
, ts-standard
etc, before migrating this one (standard-engine
).
for some i think the transition could be easy as many are just executed from cli like so: npx standard
so it would not mater what version you use... but then there is half of which that actually use standard scripting-wise
@Divlo Okay with you if we close this as completed?
@Divlo Okay with you if we close this as completed?
@voxpelli Why? This is not completed?
Honestly, I think, we can start the migration in standard-engine
if anyone wants to do so even if ts-standard
is currently blocked. Of course, the best would be to solve the issue of the ts-standard
rewrite first and then do this migration here.
@Divlo Remembered wrongly that we had already done the move here, that this was only open due to ts-standard
not having adopted it.
Then let’s get the ESM:ing started rather than waiting for ts-standard
👍
Unlikely to be done.
We should use ESM imports instead of CommonJS. See: https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c We'll be able to merge #238, #247, and #262 (dependencies updates that only work with ESM) after this change.
Note: It is a BREAKING CHANGE as
standard-engine
will only work with ESM.To offer a smoother transition for packages that depends on
standard-engine
, we should first migrate them to ESM.Status