GeezerVison

TypeScript Bot (@typescript-bot) pack this

Heya Wesley Wigham (@weswigham), I've started to run the tarball bundle task on this PR at 00d3e60. You can monitor the build here.

Hey Wesley Wigham (@weswigham), I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/104705/artifacts?artifactName=tgz&fileId=481F6DA0E8E4327055734581079A1C759EB09FE0C4041C50E8A0F65A8B9676F202&fileName=/typescript-4.4.0-insiders.20210608.tgz"
    }
}

and then running npm install.

There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/[email protected]".;

TypeScript Bot (@typescript-bot) pack this

Heya Wesley Wigham (@weswigham), I've started to run the tarball bundle task on this PR at 632b495. You can monitor the build here.

TypeScript Bot (@typescript-bot) test this

Heya Wesley Wigham (@weswigham), I've started to run the extended test suite on this PR at 632b495. You can monitor the build here.

Hey Wesley Wigham (@weswigham), I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/104964/artifacts?artifactName=tgz&fileId=1B21432CD9A5F605C89C976D8B4E5AE17B6882129C5341748B3F95D68561BDA202&fileName=/typescript-4.4.0-insiders.20210614.tgz"
    }
}

and then running npm install.

There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/[email protected]".;

TypeScript Bot (@typescript-bot) test this

Heya Wesley Wigham (@weswigham), I've started to run the extended test suite on this PR at 632b495. You can monitor the build here.

Andrew Branch (@andrewbranch) considering this doesn't add any of the new resolution rules yet (except format detection), I think that's probably fine to leave as-is until those are in place.

What are we waiting on?

Albert Marashi (@AlbertMarashi) This is a fairly large change which we will likely land in 4.5. It likely needs further review and we will need to walk it through a few scenarios to see how well it works.

Hello, your beta announcements are asking for feedback on this feature. First of all - I'm super excited about this! Great work!

One thing I was really looking forward to in Node.js exports/ESM support was having example files that import from the library itself - this way we can just say import { foo } from "my-module" rather than import { foo } from ".." /* TODO: replace this with "my-module" */ - makes it much easier for users to copy/paste examples whilst keeping the examples co-located inside the package.

Node.js supports this "self-referencing" behaviour; however TypeScript doesn't seem to understand how to import this in module:"nodenext" mode - a could not find a declaration file for module 'my-module' error is raised.

I've prepared a minimal reproduction here with js folder working using Node.js and analogous ts folder which is not working with TypeScript (won't compile):

https://github.com/benjie/typescript-self-referencing-issue

TSConfig:

{
  "compilerOptions": {
    "lib": ["es2021"],
    "module": "nodenext",
    "target": "es2021",

    "strict": true,

    "rootDir": "src",
    "declaration": true,
    "declarationDir": "dist",
    "outDir": "dist"
  },
  "include": ["src"],
  "exclude": ["dist"]
}

TypeScript version 4.6.0-dev.20211110

Maybe this relates to #46212?

Thanks for your hard work on TypeScript ❤️

Benjie (@benjie) thanks for the feedback! It works after you do a build once and dist/index.d.ts is present. I think this is a bug—it seems like we need to map back from outDir to the root. I’ve copied your report to #46762.

Thanks Andrew Branch (@andrewbranch)! When I did a second build afterwards it told me I was trying to overwrite source files; I tried adding exclude but that didn’t solve it.

Orta Therox (@orta) on the topic of extensions, there needs to be more clarification about how to handle things during development. Specific questions:

• The import/no unresolved eslint rule complains about the file not existing, recommend just disabling that rule?
• Due to this change/standardization of convention regarding file extensions, what is a good general way of "always" handling extensions across a large TS project? (working across both browser and node)

sugar import = require to require-or-createRequire and allow try-catch?

import WebStream = require('stream/web') ?? require('web-streams-polyfill/dist/ponyfill.js')

try {
  require('stream/web')
} catch {
  require('web-streams-polyfill/dist/ponyfill.js')
}

Hello, one of the features gated by "moduleResolution": "nodenext" is the per-export types mentioned at https://devblogs.microsoft.com/typescript/announcing-typescript-4-5-beta/#packagejson-exports-imports-and-self-referencing.

Basically if a dependency has a package.json like:

{
  "exports": {
    "./subpath": {
      "import": "./esm/subpath/index.js",
      "require": "./commonjs/subpath/index.js",
      "types": "./types/subpath/index.d.ts"
    }
  }
}

the "types" field above will not be looked up by a user of that dependency unless they have "moduleResolution": "nodenext" in their tsconfig.

Would the team be open to extending this feature to "moduleResolution": "node"? It's difficult that a library opting into the exports["subpath"].types feature extends a config requirement to its users. Sure that's the point of "moduleResolution" but I noticed that the other features gated by "moduleResolution": "nodenext" are more in the spirit of organising your own code. I think this would be very non-breaking in practice.

reverse ref denoland/dnt#205

No. Old node (ie, pre 12), doesn't support exports. So it won't be getting support for resolution features the matching runtime doesn't have. :)

As is, our checking is actually very useful for indicating if and how a package, as written, will work on the targeted module runtime. (Which, y'know, it might not)

See #50153 for what we're actually thinking about doing - we know stuff like deno wants more flexible resolution, but we're not going to reduce safety for people using other platforms to achieve it.

(Also, as an aside, that example export map, while vaguely functional, is incomplete - it shares types between two formats of entry points, which will create subtle (or not so subtle if the types are esm format) bugs on cross format-interop checking. Each of the require and import conditions should have it's own nested types entry. Rule of thumb: one js file, one .d.ts file. No being cute and trying to share (though you may re-export cjs format types from esm ones pretty easily). Also, order matters - conditions are matched in order, so if require or import or default or node comes before types, we'll never look at the types location, because a prior condition matched. This is export map spec'd behavior, so try not to blame us - you can't resolve compound (nested) conditions and null mappings without this behavior.)

See #50153 for what we're actually thinking about doing - we know stuff like deno wants more flexible resolution, but we're not going to reduce safety for people using other platforms to achieve it.

No worries, some conflation there as it's not a Deno concern at all but just a quirk of dnt's current exports generation (for node) that made me notice this. Fair points otherwise. To pivot slightly, the default "moduleResolution" value will eventually be one that supports exports, right? And if it's not breaking for TS, having the default match the latest version of Node seems logical to me since Node's resolution isn't designed to break as well.

(Also, as an aside, that example export map, while vaguely functional, is incomplete - it shares types between two formats of entry points, which will create subtle (or not so subtle if the types are esm format) bugs on cross format-interop checking. Each of the require and import conditions should have it's own nested types entry.

I got that from https://devblogs.microsoft.com/typescript/announcing-typescript-4-5-beta/#packagejson-exports-imports-and-self-referencing. Is there a syntax for giving different types to each condition?

the default "moduleResolution" value will eventually be one that supports exports, right?

The tsc --init default will probably be updated soonish, maybe. We'll probably discuss it after we handle that issue I linked. The compiler default we may change, but likely on a much longer timescale, since it's a breaking change.

I got that from

Daniel Rosenwasser (@DanielRosenwasser) can we get that example in the beta post fixed for googleability? I thought we did ages ago (maybe we only fixed it in the release post) - it should be

// package.json
{
    "name": "my-package",
    "type": "module",
    "exports": {
        ".": {
            // Entry-point for `import "my-package"` in ESM
            "import": 
                // Entry-point for TypeScript resolution
                "types": "./types-esm/index.d.ts"
                 // Runtime entry-point
                "default": "./esm/index.js"
            },

            // Entry-point for `require("my-package") in CJS
            "require": {
                // Entry-point for TypeScript resolution
                "types": "./types-cjs/index.d.cts"
                 // Runtime entry-point
                "default": "./commonjs/index.cjs"
            },
        },
    },

    // CJS fall-back for older versions of Node.js
    "main": "./commonjs/index.cjs",

    // Fall-back for older versions of TypeScript (will usually be treated as cjs by older TS)
    "types": "./types-esm/index.d.ts"
}

Also I got to the 4.5 beta release post from https://www.typescriptlang.org/tsconfig#moduleResolution, that should be upgraded to the 4.7 release post.

The compiler default we may change, but likely on a much longer timescale, since it's a breaking change.

I’m really looking forward to this point, since it will allow me as a library author to simplify and deduplicate some “gotcha” workarounds. Is there an appropriate place to track this/would it be alright to file a new issue for that?

I don't think we have an issue tracking it, it's just something we're keeping at the back of our minds.

Rule of thumb: one js file, one .d.ts file

Wesley Wigham (@weswigham) what does that mean for community-maintained packages in DefinitelyTyped? Say we're typing a CJS library that starts shipping both module formats using exports, but continues to avoid shipping in-package type defs. Should the corresponding @types package ship an exports field with separate .d.ts files under exports.import.types and exports.require.types?

ETA: it would be super helpful to point to a random package on DT that does this the "right" way already.