Improve OXC Support #76
Conversation
As `oxc-parser` will emit `ParenthesizedExpression`s, we need to wrap
them in parenthesis, otherwise the printed code may be unparsable, for
example in the case of the following:
```typescript
// Parse using `oxc-parser
(()=>{
console.log("I am an IIFE");
})();
```
Which was previously printed as
```
()=>{
console.log("I am an IIFE");
}();
// ^ lack of paren makes this syntactically invalid
```
`oxc-parser` emits AST nodes that do not contain `loc` fields, but rather `start` and `end` indicies. Unfortunately, that means we cannot add support for those by default, as due to the sourcemap specification being from the depths of hell, we must provide a line and column number, and thus must have the original source code to convert from the index to line-and-column.
🦋 Changeset detectedLatest commit: 46d8108 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
commit: |
|
It appears that there is a |
|
Looks like (to my knowledge), I can't make this a draft myself. Hopefully by the time you see this it will be done anyways. |
|
Converted it to a draft for you! |
|
I asked for it to be made a draft before I made the changes I had liked to make, now I believe it ready to merge (with some review). |
|
This is ready for review (and has been for a while), sorry for the mixup with me asking for it to be made a draft before I had finished it. |
src/context.js
Outdated
| @@ -104,13 +122,22 @@ export class Context { | |||
| throw new Error(message); | |||
| } | |||
|
|
|||
| if (node.start && this.#sourceText) { | |||
There was a problem hiding this comment.
Could fail if start is 0 (same below for node.end though that's even less likely)
There was a problem hiding this comment.
Good catch! Fixed
This reverts commit f261f2a.
This pull request makes the following improvements:
ParenthesizedExpressions, we would just naively print the node inside of it, instead of parenthesizing it. I am not quite sure why, but that is now fixed.[1]resolveIndexedLocationsWhy is this needed?
Sourcemaps don't let you explicitly specify the index of a location, but rather require a row and column number. This would be fine (if not slightly silly), if it weren't for the output of `oxc-parser` containing `start` and `end` fields, which use indicies rather than row and column numbers. Thus, we must have the original source code to turn said indicies into row and column numbers, which is not guranteed with the typical `print` api, so I created a wrapper around normal languages (which requires the source code to create), that adds a catch-all function to support the `oxc` style nodes. If I had more time, I could've made this more concise, sorry.And of course, I added changesets for these as well.
[1]I didn't just do this because it seemed off, it was actively causing problems because of how
oxc-parserparses IIFEs