Again, performance should be taken into account, synckit has better performance, TypeScript and native PnP support, etc.

This is not really cool.

I don't really care people using my package or not, just trying to help.

I don't even know what "TypeScript and native PnP support" mean, as I understand they all use Node.js loaders, and worker automatically inherit them, libs don't need do anything. Anyway, make-synchronized already tested loader support.

Feel feel to revert.

I don't even know what "TypeScript and native PnP support" mean

See jest failng test case: jestjs/jest#15546

That's not related at all...

This is not the right place to discuss this. Feel free to open an issue at make-synchronized if you find bugs.

That's not related at all...

Not sure what's your meaning:

/Users/runner/work/jest/jest/packages/jest-snapshot/src/__tests__/printSnapshot.test.ts

  ● Test suite failed to run

    TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts" for /Users/runner/work/jest/jest/packages/jest-snapshot/src/prettier.ts

as I understand they all use Node.js loaders, and worker automatically inherit them, libs don't need do anything

This is incorrect for PnP at least. There is no auto inherit at all.

Before I revert, do we have some benchmarks showing the better performance?

@brettz9 See https://github.com/un-ts/synckit#benchmark

Sometimes even better: https://github.com/un-ts/synckit/actions/runs/14015583415/job/39240872165#step:7:1

🎉 This issue has been resolved in version 50.6.9 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)

Your semantic-release bot 📦🚀

@brettz9

I found something interesting when playing with parse-imports.

parseImportsSync from parse-imports is much faster.

┌─────────┬────────────────────────────────┬──────────────────┬───────────────────┬────────────────────────┬────────────────────────┬─────────┐
│ (index) │ Task name                      │ Latency avg (ns) │ Latency med (ns)  │ Throughput avg (ops/s) │ Throughput med (ops/s) │ Samples │
├─────────┼────────────────────────────────┼──────────────────┼───────────────────┼────────────────────────┼────────────────────────┼─────────┤
│ 0       │ '[SYNC ] parseImportsSync'     │ '42196 ± 0.80%'  │ '39284 ± 371.00'  │ '24703 ± 0.14%'        │ '25456 ± 243'          │ 23699   │
│ 1       │ '[ASYNC] parseImports'         │ '41969 ± 0.66%'  │ '39824 ± 340.00'  │ '24599 ± 0.11%'        │ '25110 ± 213'          │ 23828   │
│ 2       │ '[SYNC ] synckit'              │ '144921 ± 1.14%' │ '131486 ± 7604.0' │ '7172 ± 0.30%'         │ '7605 ± 460'           │ 6901    │
│ 3       │ '[SYNC ] makeSynchronized'     │ '137073 ± 0.82%' │ '126431 ± 9502.0' │ '7532 ± 0.29%'         │ '7909 ± 633'           │ 7296    │
│ 4       │ '[SYNC ] makeSynchronized 0.3' │ '186558 ± 1.29%' │ '185787 ± 21090'  │ '5587 ± 0.38%'         │ '5383 ± 590'           │ 5361    │
└─────────┴────────────────────────────────┴──────────────────┴───────────────────┴────────────────────────┴────────────────────────┴─────────┘

I understand it should wait for wasmLoadPromise, I think you can do this, if you care about perf

let parse = functionSynchronizedWithWhatever

wasmLoadPromise.then(() => {
  // Swith parse to the original one
  pares = parseImportsPackage.parseImportsSync
})

const parseImports = code => parse(code)

parse-imports seems a nice package, we can also use it in eslint-plugin-import-x. cc @SukkaW

parse-imports

No, I'd rather use the battle-tested es-module-lexer directly over this wrapper package parse-imports. In fact, I have already made the es-module-lexer sync in guybedford/es-module-lexer#185.

I created the proposal months ago, but haven't got time to get my hands on implementing it. un-ts/eslint-plugin-import-x#201