You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to provide intuitive and seamless editing in a JavaScript IDE scenario (i.e. no knowledge of, or desire to interact with, the TypeScript powered typing), the experience should be simple and intuitive. By default, TypeScript will provide definitions for the core APIs, which include the standard JavaScript and DOM APIs. This should be easily configurable to provide the JavaScript APIs and the Node module definitions for NodeJS development.
As the developer adds JavaScript libraries, the type definitions for that library should also be provided. Initially, this may require manually downloading and placing in a folder included in the compilation. Eventually this should be largely automated and done invisibly in the background. For NPM modules these could be easily paired together, by matching the module name (and version) registered in NPM to the correct type definition. For JavaScript libraries, there are a number of well known libraries that could be easily detected based on name (e.g. jquery, angular, react, knockout, etc...), and a search and install utility could be provided for more general libraries. (The tsd utility today provides similar capabilities).
As the type inference (and maybe even definitions) will not be accurate in all scenarios, the IDE should also provide affordances for selecting from the broader list of identifiers in the project, or manually entering any completions.
Sample project layout
Projects should continue to use the tsconfig.json settings file to describe a folder based unit of code. As such, an example NodeJS project, with server and client code, may be laid out something like the below. Here the tsconfig.json file would contain the appropriate settings for the folder, i.e. in the server folder it would set the module type to CommonJS, and in the client folder it would set the module type to amd and enable any jsx flags needed.
Outline the completion list and signature help experience for unknown members (i.e. showing all identifiers from the project in the dropdown list with a different affordance after the initial list of infered members)
Propose a mechansim for automatically locating and aquiring correct .d.ts files for libraries and packages
Describe use of the proposed --lib option to set the right core libraries for ECMAScript version, browser DOM, NodeJS, etc.
Outline a basic workflow for coding in environments such as Visual Studio, VSCode, Sublime, Atom, Vim, etc.
The text was updated successfully, but these errors were encountered:
JavaScript developer experience
(See parent issue #4789 for an overview)
In order to provide intuitive and seamless editing in a JavaScript IDE scenario (i.e. no knowledge of, or desire to interact with, the TypeScript powered typing), the experience should be simple and intuitive. By default, TypeScript will provide definitions for the core APIs, which include the standard JavaScript and DOM APIs. This should be easily configurable to provide the JavaScript APIs and the Node module definitions for NodeJS development.
As the developer adds JavaScript libraries, the type definitions for that library should also be provided. Initially, this may require manually downloading and placing in a folder included in the compilation. Eventually this should be largely automated and done invisibly in the background. For NPM modules these could be easily paired together, by matching the module name (and version) registered in NPM to the correct type definition. For JavaScript libraries, there are a number of well known libraries that could be easily detected based on name (e.g. jquery, angular, react, knockout, etc...), and a search and install utility could be provided for more general libraries. (The
tsd
utility today provides similar capabilities).As the type inference (and maybe even definitions) will not be accurate in all scenarios, the IDE should also provide affordances for selecting from the broader list of identifiers in the project, or manually entering any completions.
Sample project layout
Projects should continue to use the
tsconfig.json
settings file to describe a folder based unit of code. As such, an example NodeJS project, with server and client code, may be laid out something like the below. Here thetsconfig.json
file would contain the appropriate settings for the folder, i.e. in theserver
folder it would set the module type toCommonJS
, and in the client folder it would set the module type toamd
and enable anyjsx
flags needed.TODO
unknown
members (i.e. showing all identifiers from the project in the dropdown list with a different affordance after the initial list of infered members).d.ts
files for libraries and packages--lib
option to set the right core libraries for ECMAScript version, browser DOM, NodeJS, etc.The text was updated successfully, but these errors were encountered: