-
-
Notifications
You must be signed in to change notification settings - Fork 196
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs: added JS doc comments and tsconfig #530
Conversation
Hi @srijan-paul!, thanks for the Pull Request The pull request title isn't properly formatted. We ask that you update the message to match this format, as we use it to generate changelogs and automate releases.
To Fix: You can fix this problem by clicking 'Edit' next to the pull request title at the top of this page. Read more about contributing to ESLint here |
695e582
to
c86b367
Compare
Hi @srijan-paul!, thanks for the Pull Request The pull request title isn't properly formatted. We ask that you update the message to match this format, as we use it to generate changelogs and automate releases.
To Fix: You can fix this problem by clicking 'Edit' next to the pull request title at the top of this page. Read more about contributing to ESLint here |
1 similar comment
Hi @srijan-paul!, thanks for the Pull Request The pull request title isn't properly formatted. We ask that you update the message to match this format, as we use it to generate changelogs and automate releases.
To Fix: You can fix this problem by clicking 'Edit' next to the pull request title at the top of this page. Read more about contributing to ESLint here |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is some fantastic work, thank you! Just a couple small suggestions.
In order for Espree to ship the type definitions, we also need to make these changes to package.json:
- Add dist/espree.d.ts to the files array.
- Add a types property that points to dist/espree.d.ts
espree.js
Outdated
* @param {Object} options Options defining how to tokenize. | ||
* @returns {Token[]} An array of tokens. | ||
* @param {ParserOptions} options Options defining how to tokenize. | ||
* @returns {import("./lib/token-translator.js").EsprimaToken[]} An array of tokens. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we move this into a typedef too?
lib/options.js
Outdated
* @property {number|"latest"} ecmaVersion The ECMAScript version to use (between 3 and 13, or 2015 and 2022, or "latest"). | ||
* @property {boolean} allowReserved Only allowed when `ecmaVersion` is set to 3. | ||
* @property {"script"|"module"|"commonjs"} sourceType The kind of the source string being parsed. | ||
* @property {import("./features").EcmaFeatures} ecmaFeatures The additional features to enable. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we move this into a typedef?
lib/espree.js
Outdated
* @property {string} text Contents of the comment. | ||
* @property {number|undefined} start Start column of a comment. | ||
* @property {number|undefined} end End column of the comment. | ||
* @property {[number, number]|undefined} range The [start, end] range of a comment. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since [number,number] is also used in EsprimaToken, can we move this into its own typedef for clarity?
Whoops, I missed adding the build file to package.json. Fixed! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good! One last step: we need to ensure that tsc
is run. In package.json
, can you add tsc
to the end of the build
script?
@@ -0,0 +1,10 @@ | |||
{ | |||
"include": ["lib/**/*", "espree.js"], | |||
"compilerOptions": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use "strict": true
in here? https://www.typescriptlang.org/tsconfig#strict
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, good point
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure it has any effects - we don't have ts code, and didn't enable "checkJs": true
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, you could be right, I thought there might be some stricter behavior/validation it might enable. Regardless, it probably wouldn't hurt to use it, especially in case we add "checkJs": true
later.
@@ -232,7 +252,7 @@ export default () => Parser => { | |||
|
|||
/** | |||
* Overwrites the default raise method to throw Esprima-style errors. | |||
* @param {int} pos The position of the error. | |||
* @param {number} pos The position of the error. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just wondering, this isn't related to acorn.Position
is it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, this was presumably done to simplify the fact that TS (and JS) doesn't distinguish regular integers and the number type. I think it would be ideal to preserve this though so as to clarify the intent, e.g., for autocomplete.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But then passing a number wouldn't satisfy TS's typechecker, no?
I'd rather have it be integer too but I think we can mention that in the parameter description since TS/JS don't have native integers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
int
would need to have its own typedef
set to number
(but if it's a problem because TypeScript will export the type, don't worry about it).
I think that would be good. Otherwise, we won't know if the definitions are broken, which would make Espree unusable in typescript projects? Speaking of that, /**
* Tokenizes the given code.
* @param {string} code The code to tokenize.
* @param {ParserOptions} options Options defining how to tokenize.
* @returns {EsprimaToken[]} An array of tokens.
* @throws {SyntaxError} If the input code is invalid.
* @private
*/
export function tokenize(code: string, options: ParserOptions): EsprimaToken[];
/**
* Parses the given code.
* @param {string} code The code to tokenize.
* @param {ParserOptions} options Options defining how to tokenize.
* @returns {acorn.Node} The "Program" AST node.
* @throws {SyntaxError} If the input code is invalid.
*/
export function parse(code: string, options: ParserOptions): acorn.Node;
export const version: "main";
export const Syntax: {};
export const VisitorKeys: any;
export const latestEcmaVersion: number;
export const supportedEcmaVersions: number[];
export type acorn = typeof acorn;
export type ParserOptions = import("./lib/options").ParserOptions;
export type EsprimaToken = import("./lib/token-translator").EsprimaToken;
export type TokenRange = import("./lib/token-translator").TokenRange;
import * as acorn from "acorn";
//# sourceMappingURL=espree.d.ts.map When I open
Also, when I try to use this version from another project (I added //----------- test.ts ---------------
import * as espree from "espree";
|
Should we then also add |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, I had neglected to see this and started my own PR which does do checkJs
, though it is not finished and probably would need changes to Acorn since Acorn declaration files apparently currently underspecify the parser, and I could rebase anyways. In any case, this was helpful to have.
I'd suggest keeping the int
type for clarifying intent and I think the @types/acorn
can be dropped given Acorn's own more current support. But otherwise LGTM...
package.json
Outdated
@@ -39,6 +41,7 @@ | |||
"@rollup/plugin-commonjs": "^17.1.0", | |||
"@rollup/plugin-json": "^4.1.0", | |||
"@rollup/plugin-node-resolve": "^11.2.0", | |||
"@types/acorn": "^4.0.6", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Acorn itself has a *.d.ts
file and the mod date appears more recent, so is this this still necessary?
@@ -232,7 +252,7 @@ export default () => Parser => { | |||
|
|||
/** | |||
* Overwrites the default raise method to throw Esprima-style errors. | |||
* @param {int} pos The position of the error. | |||
* @param {number} pos The position of the error. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, this was presumably done to simplify the fact that TS (and JS) doesn't distinguish regular integers and the number type. I think it would be ideal to preserve this though so as to clarify the intent, e.g., for autocomplete.
TypeScript allows an |
Will update this over the weekend. Got caught with life there. |
4b4b41b
to
24d1358
Compare
Co-authored-by: Milos Djermanovic <[email protected]> Co-authored-by: Bryan Mishkin <[email protected]>
24d1358
to
f8ce0d2
Compare
Co-authored-by: Milos Djermanovic <[email protected]> Co-authored-by: Bryan Mishkin <[email protected]>
Updated the PR (squashed some commits). Should be ready to go now :) @mdjermanovic I've fixed the issue with incorrectly generated .d.ts. I'm not sure what the best way would be to test the d.ts files though. Suggestions welcome. |
Hya, not to rush anyone, but I was wondering if I could get some feedback on this PR since I'd be needing the type definitions in a typescript project I'm working on :p |
@brettz9 @mdjermanovic any followups here? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My suggestion to add int
to its own typedef (e.g., /** @typedef {number} int */
) wasn't addressed, but it is not important.
Am preoccupied with other work to do a more careful review of the subsequent changes, but it had looked good to me previously.
I'm still seeing the problems described in #530 (comment):
|
espree.js
Outdated
* @param {Object} options Options defining how to tokenize. | ||
* @returns {ASTNode} The "Program" AST node. | ||
* @param {ParserOptions} options Options defining how to tokenize. | ||
* @returns {acorn.Node} The "Program" AST node. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Object returned from parse()
also has sourceType
property, and (optionally) comments
and tokens
properties.
Maybe we could use |
"shelljs": "^0.3.0" | ||
"shelljs": "^0.3.0", | ||
"typescript": "^4.5.4", | ||
"unicode-6.3.0": "^0.7.5" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we're not using this dependency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're using it in tests/lib/libraries.js
@@ -69,7 +73,7 @@ | |||
"test": "npm-run-all -p unit lint", | |||
"lint": "eslint \"*.?(c)js\" lib/ tests/lib/", | |||
"fixlint": "npm run lint -- --fix", | |||
"build": "rollup -c rollup.config.js", | |||
"build": "rollup -c rollup.config.js && tsc --build", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need the --build
flag, what is the difference?
espree.js
Outdated
@@ -124,8 +131,8 @@ export function tokenize(code, options) { | |||
/** | |||
* Parses the given code. | |||
* @param {string} code The code to tokenize. | |||
* @param {Object} options Options defining how to tokenize. | |||
* @returns {ASTNode} The "Program" AST node. | |||
* @param {ParserOptions} options Options defining how to tokenize. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* @param {ParserOptions} options Options defining how to tokenize. | |
* @param {ParserOptions} [options] Options defining how to parse. |
lib/token-translator.js
Outdated
* @property {number|undefined} start start column. | ||
* @property {number|undefined} end end column. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are not columns, but indexes (like range[0]
and range[1]
)
/** | ||
* @typedef {Object} EsprimaComment | ||
* @property {"Block"|"Line"} type Type of the comment, can either be "Block" (multiline) or "Line" (single line). | ||
* @property {string} text Contents of the comment. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* @property {string} text Contents of the comment. | |
* @property {string} value Contents of the comment. |
lib/espree.js
Outdated
* @property {number|undefined} start Start column of a comment. | ||
* @property {number|undefined} end End column of the comment. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lib/espree.js
Outdated
* @property {acorn.Position} startLoc Start location of the comment. | ||
* @property {acorn.Position} endLoc End location of the comment. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are no startLoc
and endLoc
properties on comments. They have loc
, like tokens.
Do we want to export types named |
Token and Comment are probably fine |
625af0c
to
cdc2891
Compare
cdc2891
to
6499862
Compare
6499862
to
b7a1e85
Compare
Ack. Looking for a way to fix the issue with broken |
Hi @srijan-paul, thank you for your work on this! Since this and #544 are attacking the same problem but #544 additionally enables type checking in the repository, we'd like to focus our efforts on #544. Please know that we appreciate your work on this so far, and if you haven't already heard from him, nzakas will be reaching out because this is exactly the sort of improvement that our contributor pool payments were designed for. I'm sorry this change won't be getting merged, but I hope to see what we've learned from this work reflected in #544 and would welcome seeing your feedback there! |
Added JS doc comments and a TSConfig that should generate the type definitions.
Note that it still may require changes.
Things that I'm curious about:
acorn.Node
as the return type forespree.parse
is safe?