-
Notifications
You must be signed in to change notification settings - Fork 535
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
Use strict eslint config in azure-service-utils #9489
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -36,7 +36,8 @@ | |
}, | ||
"dependencies": { | ||
"@fluidframework/protocol-definitions": "^0.1027.1000", | ||
"jsrsasign": "^10.2.0" | ||
"jsrsasign": "^10.2.0", | ||
"uuid": "^8.3.1" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This dependency was completely missing. I think the only reason it has been building OK is because of lerna dependency hoisting. |
||
}, | ||
"devDependencies": { | ||
"@fluidframework/build-common": "^0.23.0", | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -28,7 +28,11 @@ export function generateToken( | |
} | ||
|
||
// Current time in seconds | ||
const now = Math.round((new Date()).getTime() / 1000); | ||
const now = Math.round(Date.now() / 1000); | ||
|
||
if (documentId === undefined) { | ||
throw new Error("documentId cannot be undefined"); | ||
} | ||
Comment on lines
+33
to
+35
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't understand why this function has a nullable documentId parameter... Could I make it required? Or use a different type for the claims? |
||
|
||
const claims: ITokenClaims & { jti: string } = { | ||
documentId, | ||
|
@@ -42,6 +46,7 @@ export function generateToken( | |
}; | ||
|
||
const utf8Key = { utf8: key }; | ||
// eslint-disable-next-line unicorn/no-null | ||
return jsrsasign.jws.JWS.sign(null, JSON.stringify({ alg:"HS256", typ: "JWT" }), claims, utf8Key); | ||
} | ||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -4,7 +4,7 @@ | |
"src/test/**/*" | ||
], | ||
"compilerOptions": { | ||
"strictNullChecks": false, | ||
"strictNullChecks": true, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Scary that this was disabled... |
||
"rootDir": "./src", | ||
"outDir": "./dist", | ||
"types": [ | ||
|
@@ -15,4 +15,4 @@ | |
"include": [ | ||
"src/**/*" | ||
] | ||
} | ||
} |
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 see what you're doing here, permitting piecemeal improvements to the ruleset. However I think an opt-in approach is slower than an opt-out approach and makes it easy for new packages to continue adopting bad habits (in much the same way that having our rules disabled for a period of time permitted decay of our code quality).
I'd suggest getting a single, strict ruleset established in the eslint package and turn it on for all packages at the same time. For packages that don't comply, use disables in their individual eslintrc as necessary. This gets the most rules enabled for the most packages in the shortest period of time, and ensures any new package is strictly enforced by default. Cleaning out eslintrc's across the repo is then just a burndown effort.
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.
Good advice, thanks. #9501 tracks all the relevant work I know of -- take a look and let me know if there's something missing.
Minor quibble -- because we don't have a proper project template or scaffold in place, people copy/paste projects, which means project-level overrides tend to follow new projects around like zombies. :)
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.
That's true, but diligent reviewers should object to new packages being added with gross disables during PR (same as they should object to incorrect README text, etc.).
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.
Who are these people you speak of? 😝