-
Notifications
You must be signed in to change notification settings - Fork 215
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
PNPM workspaces #663
PNPM workspaces #663
Conversation
linting starts and then fails because tests can't resolve their types packages
I'm at the point of checking `version` and I think I need to copy code from definition-parser maybe. Visions of semver parsing...
It's already written! Also make deepEqual traverse ojbects as well as arrays.
Show all unused files at once, not just the first unused one.
Deletes a whole bunch of stuff and simplifies or reworks others. I noticed that we still want to walk the file looking for globals SO I have to put back in huge chunks of code I took out. Creating a commit so I can diff on github.
Everything builds now!
It's only one line of code now
Also all (?) the infrastructure needed to support it.
self-references sometimes result in doubled 'node_modules/@types/self-package-name' prefixes.
Lots of code churn and probable bugs, but no real functionality change right now. In the future this makes it much easier to mimic real ES module layouts.
Plus update typescript again to match DT
2. Simplify and reduce JSON parsing in dtslint-runner. Pass around AllPackages object instead of writing it to disk and reading it over and over. 3. Sort AllPackages object before returning it in addition to before writing it to disk.
Still not 100% semver, but the common paths now use it.
Only a few fixes needed this time!
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.
Okay overall seems good, with some general notes of:
- Seems like there may be some inconsistency in the use of
.typesDirectoryName
and.name
- I think we should be able to drop parsimmon as a dep for the header parser now? May be worth running depcheck on the repo (or knip)
@@ -139,8 +139,8 @@ export async function fetchTypesPackageVersionInfo( | |||
if (info.deprecated) { | |||
// https://github.com/DefinitelyTyped/DefinitelyTyped/pull/22306 | |||
assert( | |||
pkg.name === "angular-ui-router" || pkg.name === "ui-router-extras", | |||
`Package ${pkg.name} has been deprecated, so we shouldn't have parsed it. Was it re-added?` | |||
pkg.typesDirectoryName === "angular-ui-router" || pkg.typesDirectoryName === "ui-router-extras", |
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.
Not sure if typesDirectoryName
includes a version or not, but maybe this should just be checking === "@types/angular-ui-router"
? Not sure what this check is doing at this point though.
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 through the referenced PR, it looks like these were a manual package rename, or maybe manual deprecation, and then later somebody tried to re-add the types.
It seems like ancient history that we shouldn't need to check for, but I also don't feel like removing it and testing retag right now.
1. Patch version is now .9999 not .99999 2. contributors -> owners 3. typeScriptVersion -> minimumTypeScriptVersion Note that the publisher should still produce a package.json with a contributor property.
packages/utils/src/assertions.ts
Outdated
@@ -34,3 +34,20 @@ export function assertSorted<T>( | |||
} | |||
return a; | |||
} | |||
|
|||
export function deepEquals(expected: unknown, actual: unknown): boolean { | |||
if (expected instanceof Array) { |
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.
shouldn't this be Array.isArray?
); | ||
} else if (typeof expected === "object") { | ||
for (const k in expected) { | ||
if (!deepEquals((expected as any)[k], (actual as any)[k])) { |
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 will crash when actual === null
. Or, actually, undefined, because it doesn't check whether typeof actual === "object"
for (const diff of diffs) { | ||
if (diff.status !== "D") continue; |
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.
It will test things that might not need to be tested (but since they're complicated enough that git didn't understand, probably should be tested.) That's all that gitDeletions is used for now.
I am not sure where, but some part of the code's linting is still suggesting putting stuff in the header:
|
yeah dts-critic's |
To correctly allow/disallow types/typesVersion in tsconfig
if ("errors" in deleteds) errors.push(...deleteds.errors); | ||
else | ||
for (const deleted of deleteds.ok as NotNeededPackage[]) { | ||
errors.push(...(await checkNotNeededPackage(deleted))); |
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.
Not proposing to change it now, but it’s really weird that this get*
function is checking something as a side effect. It’s also weird that a function that’s supposed to “get affected packages” takes a parameter for whether you want... the affected packages... or all of them 🤔
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 also just noticed that selection
can be a regex, and that there's code to run only packages that match 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.
Moments later: This code is only called with "affected"; "all" and regexes are unused. I deleted the dead code.
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've looked pretty thoroughly at
- definitions-parser
- header-parser
and personally tested publisher pretty thoroughly. I haven't looked closely at dtslint, dtslint-runner, or eslint-plugin, but you've been testing those on DT as we go. So, I think I feel pretty good.
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.
Seems good to me now, with the one comment about whether or not we should suggest a non-conflicting name in the new lint message.
// Type definitions for non-npm package ${name}-browser | ||
|
||
Add -browser to the end of your name to make sure it doesn't conflict with existing npm packages.`, | ||
2. Add \`"nonNpm": true\` to the package.json to indicate that this is not an npm package. |
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.
Should we still suggest the -browser
suffix as an example?
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.
It's kind of a separate question from this PR. There are enough non-node environments now that we might want to explain that in the message, but it makes it even more complicated.
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.
Yeah, we can do this later. -browser
leads to people tacking -browser
to their name to silence the lint even if it doesn't make any sense... Saw that once already last week.
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.
Yeah, I felt that advice was very outdated at best
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.
Seems good to me now, with the one comment about whether or not we should suggest a non-conflicting name in the new lint message.
Also, are we requiring |
nonNpmDescription is required when nonNpm is specified, and not allowed when it is not. |
It has a bunch of dead code!
Current progress:
react and node fail with errors now, which I need to look at.
TODO: