lucene: feat: Support ranged node terms

[kf6kjg]

This is a much closer match to the actual data structures produced by the Lucene package. I've been using this patch for several months in a couple of private projects for a company I did work for.

Also along for the ride is that the similarity field is a nullable number. Again, matches the actual code of Lucene, but not as well used in my code.

These types were created by carefully reading and extracting the critical parts from the grammar file that I used in my code, so I make no guarantee that it's 100% complete, only that it's better than it was.

Please fill in this template.

• Use a meaningful title for the pull request. Include the name of the package modified.
• Test the change in your own code. (Compile and run.)
• Add or edit tests to reflect the change. (Run with npm test YOUR_PACKAGE_NAME.)
• Follow the advice from the readme.
• Avoid common mistakes.
• Run npm run lint package-name (or tsc if no tslint.json is present).

Select one of these and delete the others:

If changing an existing definition:

• Provide a URL to documentation or source code which provides context for the suggested changes: https://github.com/bripkens/lucene/blob/master/lib/lucene.grammar
• If this PR brings the type definitions up to date with a new version of the JS library, update the version number in the header.
• Include tests for your changes
• If you are making substantial changes, consider adding a tslint.json containing { "extends": "dtslint/dt.json" }. If for reason the any rule need to be disabled, disable it for that line using // tslint:disable-next-line [ruleName] and not for whole package so that the need for disabling can be reviewed.

[typescript-bot]

@kf6kjg Thank you for submitting this PR! I see this is your first time submitting to DefinitelyTyped 👋 — I'm the local bot who will help you through the process of getting things through.

This is a live comment which I will keep updated.

This PR doesn't modify any tests, so it's hard to know what's being fixed, and your changes might regress in the future. Have you considered adding tests to cover the change you're making? Including tests allows this PR to be merged by yourself and the owners of this module. This can potentially save days of time for you.

1 package in this PR

• lucene on npm, on unpkg

Code Reviews

This PR can be merged once it's reviewed by a DT maintainer.

Status

• ✅ No merge conflicts
• ✅ Continuous integration tests have passed
• ❌ Only a DT maintainer can approve changes without tests

Once every item on this list is checked, I'll ask you for permission to merge and publish the changes.

---

Diagnostic Information: What the bot saw about this PR

{
  "type": "info",
  "now": "-",
  "pr_number": 48624,
  "author": "kf6kjg",
  "owners": [
    "bengry",
    "HugoMuller"
  ],
  "dangerLevel": "ScopedAndUntested",
  "headCommitAbbrOid": "b2c2242",
  "headCommitOid": "b2c2242531a238d9f7091813597fb90763cf635d",
  "mergeIsRequested": false,
  "stalenessInDays": 0,
  "lastPushDate": "2020-10-13T18:08:48.000Z",
  "lastCommentDate": "2020-10-14T15:00:10.000Z",
  "maintainerBlessed": false,
  "reviewLink": "https://github.com/DefinitelyTyped/DefinitelyTyped/pull/48624/files",
  "hasMergeConflict": false,
  "authorIsOwner": false,
  "isFirstContribution": true,
  "popularityLevel": "Well-liked by everyone",
  "newPackages": [],
  "packages": [
    "lucene"
  ],
  "files": [
    {
      "path": "types/lucene/index.d.ts",
      "kind": "definition",
      "package": "lucene"
    }
  ],
  "hasDismissedReview": false,
  "ciResult": "pass",
  "lastReviewDate": "2020-10-14T15:00:21.000Z",
  "reviewersWithStaleReviews": [],
  "approvalFlags": 2,
  "isChangesRequested": false
}

[typescript-bot]

🔔 @bengry @HugoMuller — please review this PR in the next few days. Be sure to explicitly select Approve or Request Changes in the GitHub UI so I know what's going on.

[typescript-bot]

👋 Hi there! I’ve run some quick measurements against master and your PR. These metrics should help the humans reviewing this PR gauge whether it might negatively affect compile times or editor responsiveness for users who install these typings.

Let’s review the numbers, shall we?

Comparison details 📊

	master	#48624	diff
Batch compilation
Memory usage (MiB)	36.5	36.6	+0.3%
Type count	2155	2171	+1%
Assignability cache size	99	99	0%
Language service
Samples taken	21	21	0%
Identifiers in tests	21	21	0%
getCompletionsAtPosition
Mean duration (ms)	82.0	82.3	+0.3%
Mean CV	21.2%	22.6%
Worst duration (ms)	108.3	106.8	-1.4%
Worst identifier	lucene	unescape
getQuickInfoAtPosition
Mean duration (ms)	76.2	75.2	-1.3%
Mean CV	18.3%	17.4%	-5.1%
Worst duration (ms)	91.5	87.9	-4.0%
Worst identifier	unescape	phrase

It looks like nothing changed too much. I won’t post performance data again unless it gets worse.

[typescript-bot]

@kf6kjg The CI build failed! Please review the logs for more information.

Once you've pushed the fixes, the build will automatically re-run. Thanks!

[bengry]

Looks good overall. I left a couple of comments though, would like some explanations before we go ahead and merge this :).

[kf6kjg]

Changes made, lemme know how that looks now. Not sure I understand the reasoning behind preferring interfaces over types, but since they are equivalent to me I made the change.

[typescript-bot]

@kf6kjg The CI build failed! Please review the logs for more information.

Once you've pushed the fixes, the build will automatically re-run. Thanks!

[typescript-bot]

@bengry Thank you for reviewing this PR! The author has pushed new commits since your last review. Could you take another look and submit a fresh review?

[bengry]

Not sure I understand the reasoning behind preferring interfaces over types, but since they are equivalent to me I made the change.

The reasoning is that interfaces, unlike types can be merged (even by outside consumers). Here's a small example showing this. Relevant docs.

Changes made, lemme know how that looks now.
See my comment in the code, the type -> interface change looks good, but I'm still seeing all interfaces being export-ed.

[kf6kjg]

As mentioned in the latest commit: strict-export-declare-modifiers requires all declarations to be exported.

[bengry]

As mentioned in the latest commit: strict-export-declare-modifiers requires all declarations to be exported.

Thanks, I haven't noticed that. LGTM.

[orta]

Thanks, great first contribution 👍🏻

[typescript-bot]

I just published @types/lucene@2.1.2 to npm.