`oxc-parser`: Export named 'parseSyncRaw' not found in module

[i-love-neko-girls]

import { parseSyncRaw } from 'oxc-parser'
parseSyncRaw(...)

> bun script.mjs
SyntaxError: Export named 'parseSyncRaw' not found in module 'node_modules/oxc-parser/index.js'.

same in Node, but it's present in type declarations

[camc314]

@overlookmotel maybe this should push us to use TS? the reason this is happening is because napi is creating a index.d.ts file next to the index.js file, and typescript thinks the types for index.js are defined in index.d.ts (in reality, index.d.ts defines the types for bindings.js

[Boshen]

@overlookmotel napi/parser/index.js doesn't have a parseSyncRaw export.

I agree with Cam, these js files are getting out of hand without a library bundler.

[overlookmotel]

Agreed it's a mess!

I'll start by getting codegen to generate type defs for the module record types. Then we'll have less types to manually define when we get rid of the types that NAPI-RS produces.

[camc314]

I'll start by getting codegen to generate type defs for the module record types. Then we'll have less types to manually define when we get rid of the types that NAPI-RS produces.

What's the reasoning for removing using the napi-rs types? (assuming napi creates the correct types). The way i'm thinking about this is we have a public declaration file (this can re-export some of the napi types), and an internal one (from napi). thgat way we can make it clear what's actually public and what isn't. Maybe worth discussing tommorow?

[overlookmotel]

Yes sure, let's discuss. There's another reason - I think we should transfer module record to JS as JSON instead of NAPI objects. That should be cheaper, and also then we can respect the new range option in module record (and loc option, when we add it). But then we can't use NAPI-RS to generate the types, as it won't know anything about them.

[Boshen]

Can we at least hotfix this issue first? Either export it properly, or make napi omit the declaration (I don't know which one we want).