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

doc: add TypeScript execution requirements #44030

Closed
wants to merge 16 commits into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
60 changes: 59 additions & 1 deletion doc/contributing/maintaining-types-for-nodejs.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ code of their JavaScript projects. While many people don't annotate their code,
or make use of annotations at all, there are enough who do that the project has
agreed it's important to work towards having [suitable types for end-users][].

## High level approach
## High level approach - maintaining types

There are a number of ways that types could be maintained for Node.js ranging
from shipping them with the Node.js runtime to having them be externally
Expand All @@ -28,6 +28,64 @@ The agreement was that the ideal flow would be as follows:
* Automation within external type projects consumes the JSON and automatically
generates a PR to add the API.

## High level approach - development workflow

The number of people using TypeScript with Node.js is significant enough
that providing a good developer experience is important. While TypeScript
is identified specifically, a secondary goal is that what we provide to improve
development experience with TypeScript would apply to other type
systems and transpiled languages as well.

We have agreed that the approach will **NOT** include bundling TypeScript
tools with Node.js but instead improve the developer experience for how
those tools are installed/configured to work with Node.js.

The high level developer experience we are working towards was captured in the
[next-10 TypeScript mini-summit](https://github.com/nodejs/next-10/pull/150)
and is as follows:

1. When Node.js is started with an entry point that is not a file type that
Node.js recognizes, for example `node script.ts`, an informative error
message is printed that directs users to a webpage where they can
learn how to configure Node.js to support that file type.
* If the file was a TypeScript file, a TypeScript specific message with a
reference to a link on Nodejs.org specific on learning how to
configure TypeScript will be provided.
* For other file types a generic message and shared webpage will be
used.
2. Node.js gains support for loading configuration from a file. Most, if not
all, of the configuration supported by `NODE_OPTIONS` would be
supported in this file (which might be the `package.json` that lives
near the entry point file). The webpage with instructions would tell
users what configuration to put in this file to get Node.js to support
their file type.
3. When Node.js is run with the correct configuration, either in a file or
`NODE_OPTIONS` or flags, the unknown file type is executed as expected.

Some additional specifics around the current approach include:

* Loaders already provide a number of the components needed to
satisfy the requirements above. They already provide the Node.js
options that are needed to achieve many of the requirements above.
* `package.json` as the location for the config is potentially a good
choice as Node.js already looks for it as part of startup.
* The implementation chosen should allow for different configuration
in/for different environments/conditions such as production
versus development, or different types of hosted environments
such as serverless vs traditional, etc.; Node.js would not make
any recommendations or have any expectations as to what the
separate configuration blocks should be named or what their
purposes should be, just that a configuration file should have
the ability to provide different configurations for user-defined
conditions.
mhdawson marked this conversation as resolved.
Show resolved Hide resolved
* There is no plan to define a default tsconfig.json for all Node.js users
* We don't have consensus on provding an opinionated default but
that should be explored after the initial steps are complete.
* It will be important that as part of the messaging around this
functionality that we avoid confusion that could lead people to ship
TypeScript files (e.g. `script.ts`) instead of the processed files
(e.g. `script.js`).
Copy link
Member

Choose a reason for hiding this comment

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

We are missing some note on tsconfig.

I think we have consensus on saying that Node.js should not dictate how TS is configured and left out to the rest of the toolchain.

Copy link
Member

Choose a reason for hiding this comment

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

I thought this was implied by the line “We have agreed that the approach will NOT include bundling TypeScript” but if you want an explicit mention of tsconfig.json, sure.

Copy link
Member

Choose a reason for hiding this comment

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

This was called out by other folks, better be precise

Copy link
Member

Choose a reason for hiding this comment

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

Can you please propose some text that would satisfy you?

Copy link
Member

Choose a reason for hiding this comment

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

* There is no plan to define a default tsconfig.json for all Node.js users

Copy link
Member Author

Choose a reason for hiding this comment

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

Added

Copy link
Member Author

Choose a reason for hiding this comment

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

@mcollina added


## Generation/Consumption of machine readable JSON files

When you run `make doc` the canonical markdown files used to
Expand Down