Skip to content
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

[node/module] (nodejs v12 and v13) Add missing types for custom require and require.cache #40456

Conversation

GeorgeTaveras1231
Copy link
Contributor

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.)
  • 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://nodejs.org/api/modules.html#modules_module_createrequire_filename
    follow the link to the return value, see that it has the same API as the global require

  • 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.
  • 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.

Add missing APIs on require.resolve from createRequire.
@GeorgeTaveras1231 GeorgeTaveras1231 changed the title [node/modules] (nodejs v12 and v13) Add missing types for custom require and require.cache [node/module] (nodejs v12 and v13) Add missing types for custom require and require.cache Nov 18, 2019
@typescript-bot typescript-bot added this to Needs Author Attention in Pull Request Status Board Nov 18, 2019
@typescript-bot typescript-bot added Popular package This PR affects a popular package (as counted by NPM download counts). The Travis CI build failed labels Nov 18, 2019
@typescript-bot
Copy link
Contributor

typescript-bot commented Nov 18, 2019

@GeorgeTaveras1231 Thank you for submitting this PR!

🔔 @microsoft @DefinitelyTyped @jkomyno @a-tarasyuk @alvis @r3nya @btoueg @BrunoScheufler @smac89 @tellnes @Touffy @DeividasBakanas @eyqs @Flarna @Hannes-Magnusson-CK @KSXGitHub @hoo29 @kjin @ajafff @islishude @mwiktorczyk @mohsen1 @n-e @octo-sniffle @galkin @parambirs @eps1lon @SimonSchick @ThomasdenH @WilcoBakker @wwwy3y3 @ZaneHannanAU @samuela @kuehlein @j-oliveras @bhongy @chyzwar @trivikr @nguymin4 - 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.

If no reviewer appears after a week, a DefinitelyTyped maintainer will review the PR instead.

@typescript-bot
Copy link
Contributor

typescript-bot commented Nov 18, 2019

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

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

Copy link
Contributor

@galkin galkin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good for me.

@GeorgeTaveras1231
Copy link
Contributor Author

@DefinitelyTyped I'm having a hard time seeing the connection between my changes and the failing benchmark CI check. I'm happy to make the necessary changes, but my first reaction is to assume there is a larger problem with the CI check, that's out of scope from this PR. Is that assumption correct? If not, I can spend a little longer looking into the error.

@typescript-bot typescript-bot added the Owner Approved A listed owner of this package signed off on the pull request. label Nov 18, 2019
@Flarna
Copy link
Contributor

Flarna commented Nov 18, 2019

@GeorgeTaveras1231 The fail looks unrelated, unforuntatelly CI is flaky here.
Best is to retrigger CI by closing and reopening the PR or pushing a commit and hope that it

Pull Request Status Board automation moved this from Needs Author Attention to Done Nov 18, 2019
@typescript-bot typescript-bot moved this from Done to Check and Merge in Pull Request Status Board Nov 18, 2019
@typescript-bot
Copy link
Contributor

A definition owner has approved this PR ⭐️. A maintainer will merge this PR shortly. If it shouldn't be merged yet, please leave a comment saying so and we'll wait. Thank you for your contribution to DefinitelyTyped!

@Flarna
Copy link
Contributor

Flarna commented Nov 18, 2019

@sheetalkamat @sandersn Could you please take a look into the failing BenchmarkPR runs?

Doesn't look related to the change done in this PR but failing CI builds (even Benchmarks) block merge (see #40263)

Error: Error: Command failed: npm install --ignore-scripts --no-shrinkwrap --no-package-lock --no-bin-links
npm ERR! code ENOENT
npm ERR! syscall lchown
npm ERR! path /home/vsts/.npm/_locks/staging-b3823d1922361c5d.lock
npm ERR! errno -2
npm ERR! enoent ENOENT: no such file or directory, lchown '/home/vsts/.npm/_locks/staging-b3823d1922361c5d.lock'

@SimonSchick
Copy link
Contributor

@typescript-bot
Copy link
Contributor

👋 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 #40456 diff
Batch compilation
Memory usage (MiB) 123.1 122.0 -0.9%
Type count 21636 21642 0%
Assignability cache size 39461 39463 0%
Language service
Samples taken 1653 1689 +2%
Identifiers in tests 11517 11553 0%
getCompletionsAtPosition
    Mean duration (ms) 686.1 679.6 -1.0%
    Mean CV 6.9% 6.8%
    Worst duration (ms) 889.1 844.6 -5.0%
    Worst identifier SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER S_IFSOCK
getQuickInfoAtPosition
    Mean duration (ms) 679.9 674.3 -0.8%
    Mean CV 6.9% 6.9% +0.8%
    Worst duration (ms) 848.3 850.4 +0.2%
    Worst identifier debug URLSearchParams

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

@typescript-bot typescript-bot added the Perf: Same typescript-bot determined that this PR will not significantly impact compilation performance. label Nov 18, 2019
@sheetalkamat sheetalkamat merged commit f4e58f2 into DefinitelyTyped:master Nov 19, 2019
Pull Request Status Board automation moved this from Check and Merge to Done Nov 19, 2019
@typescript-bot
Copy link
Contributor

I just published @types/node@12.12.10 to npm.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Owner Approved A listed owner of this package signed off on the pull request. Perf: Same typescript-bot determined that this PR will not significantly impact compilation performance. Popular package This PR affects a popular package (as counted by NPM download counts).
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants