Skip to content

Provide easier access to object in JavaScript JSDoc #34980

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

Closed
5 tasks done
ExE-Boss opened this issue Nov 7, 2019 · 3 comments · Fixed by #35661
Closed
5 tasks done

Provide easier access to object in JavaScript JSDoc #34980

ExE-Boss opened this issue Nov 7, 2019 · 3 comments · Fixed by #35661
Labels
Breaking Change Would introduce errors in existing code Fixed A PR has been merged for this issue In Discussion Not yet reached consensus Suggestion An idea for TypeScript

Comments

@ExE-Boss
Copy link
Contributor

ExE-Boss commented Nov 7, 2019

Search Terms

Suggestion

There should be a compiler option like strictJSDocTypes or something to disable the object to any conversion present in TypeScript’s JSDoc parser.

Use Cases

I’m currently forced to use:

/** @typedef {NonNullable<Parameters<typeof Object.create>[0]>} obj */

to get a reference to TypeScript’s object type.

Examples

Any code where I use the above.


The following code creates an object with writable, configurable and non‑enumerable properties:

var ES = require("es-abstract");
var define = require("define-properties");
var $ObjectCreate = GetIntrinsic("%Object.create%", true);

/**
 * @template {object} M
 * @param {object | null} proto
 * @param {M & ThisType<any>} [props]
 * @return {object}
 */
function createObj(proto, props) {
	var result = ES.ObjectCreate(proto);
	if (arguments.length > 1) {
		define(result, props);
	}
	return result;
}

All instances of object in the above code currently have to be replaced with the obj type alias.

Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.
@andrewbranch
Copy link
Member

@sandersn my understanding from microsoft/TypeScript-New-Handbook#36 was that object was no longer rewritten to any as of 3.7, but it doesn’t seem like that’s the case?

Neither object nor Object have defined properties or string index
signatures, which means that they give too many errors to be useful in
Javascript. Until Typescript 3.7, both were rewritten to any, but we
found that few people used object in JSDoc, and that more and more
JSDoc authors wanted to use object with its Typescript meaning. The
rewrite Object -> any is disabled when "noImplicitAny": true,
which the compiler takes as a signal that the code is being written
with Typescript in mind.

@andrewbranch andrewbranch added In Discussion Not yet reached consensus Suggestion An idea for TypeScript labels Dec 10, 2019
@sandersn
Copy link
Member

derp! yes, I misread the code when writing that new text. getIntendedTypeFromJSDocTypeReference doesn't handle object, so I assumed that a discussion I had earlier about turning off object -> any had resulted in the change. But actually it only operates on type references, not keywords. object is a keyword, so it's handled in getTypeFromTypeNode.

I need to track down that discussion, because I think it had some analysis of actual usage.

@sandersn
Copy link
Member

But in summary:

  1. We want to do this.
  2. I thought we already did this.
  3. We should make sure that lots of JS code isn't currently using object to mean any the way we've observed Object being used.

@DanielRosenwasser DanielRosenwasser added the Breaking Change Would introduce errors in existing code label Dec 23, 2019
@DanielRosenwasser DanielRosenwasser added this to the TypeScript 3.8.0 milestone Dec 23, 2019
@DanielRosenwasser DanielRosenwasser added the Fixed A PR has been merged for this issue label Dec 23, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Breaking Change Would introduce errors in existing code Fixed A PR has been merged for this issue In Discussion Not yet reached consensus Suggestion An idea for TypeScript
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants