overlookmotel
commented
1 month ago @Boshen and I discussed on video call just now. He's given his 👍 to this.
Open overlookmotel opened 1 month ago
overlookmotel
commented
1 month ago @Boshen and I discussed on video call just now. He's given his 👍 to this.
dalisoft
commented
1 month ago @overlookmotel Supporting TypeScript interfaces for program also would be helpful or using as TypeScript object as const which returns RAW data as type
overlookmotel
commented
1 month ago Hi @dalisoft. Sorry but I don't quite understand what you mean. I'm not much of a TypeScript user, so perhaps that's the reason. Could you possibly elaborate?
dalisoft
commented
1 month ago @overlookmotel
const funcString =
/**
*
* @returns {{status: 'success' | 'error'}}
*/
(async (req, res) => {
const var1 = req.headers['X-Telemetry-ID'];
const var2 = req.cookies['X-User-ID'];
useEffect(() => {
let unload;
const initTelemetry = async () => {
await xUserConnect(req.params['x-user-id']);
({ unload } = await loadTelemetryApp(var1));
};
initTelemetry();
return unload;
}, [var1, var2]);
const result = await someExpensiveTask();
const confirm = await waitToConfirm(req, result);
const { cookies } = req;
const { send } = res;
const queries = req.queries;
const { compress } = req.queries;
const { check_zstd } = queries;
const values = [req.body];
const foo = {
bar: req.body.bar
};
const template = `${req.params.mailId}`;
await testMe(queries.elemId);
shouldSync(req.params);
await checkAuth(req.headers, req.cookies);
await itWorks(result, confirm);
itWorksSync(confirm);
await (async () => {
await someSQLTask();
})();
return { status: 'success' };
}).toString();
const oxcParserResult = await oxcParser.parseAsync(funcString, {
sourceType: 'unambiguous',
sourceFilename: `route-${i}.ts`,
preserveParens: true
});
const { errors, comments, program } = oxcParserResult;
// program is `string` at here, but as this issue propose is using `JS` instead of `JSON` string, i would like to expect `TypeScript types` too// This is for example, this interface/type could be improved
// with type-based properties like `body` or `properties`
interface ASTNode {
type:
| 'Program'
| 'ExpressionStatement'
| 'ArrowFunctionExpression'
| 'CallExpression' /* so on other types */;
start: number;
end: number;
body?: ASTNode[];
}
const { errors, comments, program } = oxcParserResult;
// program is `ASTNode` at here for better completionas const)ast-tree.tsoverlookmotel
commented
1 month ago Ah ha. Thanks for clarifying. We are working on infrastructure to generate TS type definitions from our internal Rust types. It'll take a little time to do that (not quite as simple as it sounds!), but it is coming.
dalisoft
commented
1 month ago Thank you @overlookmotel
if there need any help at JavaScript/TypeScript-side or any testing, i would like to help with that
overlookmotel
commented
1 month ago Thanks very much for the offer. I've made a note to call on you when we have type def generation working.
escaton
commented
1 month ago @dalisoft could you please help me understand how Propose 2 can work with dynamic value?
dalisoft
commented
1 month ago @escaton It will work as expected because all values (even dynamic) will be as types so it gets as 1 | 2 for example instead of type number.
escaton
commented
1 month ago In order for TS to infer something with as const assertion, that something needs to be literal, which is impossible for dynamic values.
From the TS diagnostic:
A 'const' assertions can only be applied to references to enum members, or string, number, boolean, array, or object literals.@escaton Seems i don’t understand what you means by dynamic values.
please give me example of dynamic values and i will try to use as const.
i am not pro TS developer, just average developer with TS experience
escaton
commented
1 month ago What happens when AST is parsed by Rust and then transferred to JS is conceptually not different from JSON.parse So how would you use as const to get type inference in this case?
const ast = JSON.parse('{"body": ["ImportDecalration","ExportDecalration"]}')
ast.body
// ^?For such case I don’t know but with for my own project i am did
escaton
commented
1 month ago Indeed, that will work, but this is not quite the mainstream usage of the ast parsers :)
danielroe
commented
1 week ago I've been looking at using the node bindings for oxc-parser (did an experiment to use oxc instead of esbuild + acorn for nuxt). Because of the slight but significant differences from acorn, it would be hugely helpful to have types for the oxc AST. Let me know if there's anything I can do to help, either in implementing the type generation, or in testing the output. 🙏
overlookmotel
commented
1 week ago @danielroe Thanks for the offer. I'm afraid that's going to be a while, because generating types is tied up with other major changes we're making to how AST data is transported from Rust to JS. And for the same reasons, it's unfortunately not something that's really accessible to contributors to work on either.
I'm really sorry that's a rubbish answer! We would dearly like to receive help from the community, but it's just a lot more complicated than it might appear. It goes deep!
When we get movement on this and have type generation working, I hope you don't mind if we take up your offer to help with testing.
At present, NPM package oxc-parser's
parse*methods return an object including AST as JSON string.I propose:
parseSyncandparseAsyncto callJSON.parseon the JSON by default, so they return AST as a JS object.json: trueto return JSON string instead (as at present).This is a breaking change, and will require bumping the package minor version (i.e. 0.21.0).
This is motivated by oxc-project/backlog#47.