Skip to content

random emit declaration #40092

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

Open
bluelovers opened this issue Aug 17, 2020 · 2 comments
Open

random emit declaration #40092

bluelovers opened this issue Aug 17, 2020 · 2 comments
Assignees
Labels
Bug A bug in TypeScript Fix Available A PR has been opened for this issue Rescheduled This issue was previously scheduled to an earlier milestone

Comments

@bluelovers
Copy link
Contributor

bluelovers commented Aug 17, 2020

TypeScript Version: 3.7.x-dev.201xxxxx

Search Terms:

Code

https://github.com/bluelovers/ws-yarn-workspaces/blob/master/packages/%40yarn-tool/npm-package-arg-util/lib/parseArgvPkgName.ts

import { npa, getSemverFromNpaResult} from '../index';
import { stripScope } from './stripScope';
import { IParsePackageName, IResult } from './types';

/**
 * @deprecated
 */
export function parseArgvPkgName(input: string)
{
	const result = npa(input)

	if (result)
	{
		return {
			input,
			namespace: result.scope,
			name: stripScope(result.name),
			version: getSemverFromNpaResult(result),
			result,
		}
	}
}

export function parsePackageName(packageName: string): IParsePackageName
{
	const result = npa(packageName)

	const subname = stripScope(result.name);

	let semver = getSemverFromNpaResult(result);

	if (!semver?.length)
	{
		semver = void 0;
	}

	return {
		type: result.type,
		name: result.name,
		scope: result.scope,
		subname,
		semver,
		result,
	}
}

Expected behavior:

emit .d.ts always same

Actual behavior:

random emit one of code

/// <reference types="npm-package-arg" />
import { IParsePackageName } from './types';
/**
 * @deprecated
 */
export declare function parseArgvPkgName(input: string): {
    input: string;
    namespace: string;
    name: string;
    version: string;
    result: import("npm-package-arg").FileResult | import("npm-package-arg").HostedGitResult | import("npm-package-arg").URLResult | import("npm-package-arg").AliasResult | import("npm-package-arg").RegistryResult;
};
export declare function parsePackageName(packageName: string): IParsePackageName;

or

import { IParsePackageName, IResult } from './types';
/**
 * @deprecated
 */
export declare function parseArgvPkgName(input: string): {
    input: string;
    namespace: string;
    name: string;
    version: string;
    result: IResult;
};
export declare function parsePackageName(packageName: string): IParsePackageName;

Playground Link:

Related Issues:

@RyanCavanaugh RyanCavanaugh added the Needs Investigation This issue needs a team member to investigate its status. label Aug 17, 2020
@RyanCavanaugh RyanCavanaugh added this to the TypeScript 4.1.0 milestone Aug 17, 2020
@weswigham
Copy link
Member

OK, yeah, initial/clean compilation produces the

/// <reference types="npm-package-arg" />
import { IParsePackageName } from './types';

variant, while watch-based recompilation produces the

import { IParsePackageName, IResult } from './types';

variant (so it's at least actually predictableish).

This happens because of the file check order causing the FileResult | HostedGitResult | URLResult | AliasResult | RegistryResult union to either be made with or without an alias. When in full program compilation, index.d.ts of npm-package-arg is read first, where the union is manufactured without an alias symbol. When in watch mode, types.ts (or the declaration file thereof) of npm-package-arg-util is read first, which gives the union an alias symbol.

@weswigham
Copy link
Member

weswigham commented Aug 18, 2020

We spoke about it for a bit, and because of the effect this has on watch mode (and the instability therein), we're willing to revist what I think is the canonical fix for this (and issues like it): Recording all aliases established for a type, rather than just optimistically recording the "first" (if it's established at the same time the type is manufactured). So I'll retriage this as Bug, and that'll be the gist of the associated fix, once it's ready.

@weswigham weswigham added Bug A bug in TypeScript and removed Needs Investigation This issue needs a team member to investigate its status. labels Aug 18, 2020
@typescript-bot typescript-bot added the Fix Available A PR has been opened for this issue label Aug 25, 2020
@RyanCavanaugh RyanCavanaugh added Rescheduled This issue was previously scheduled to an earlier milestone and removed Rescheduled This issue was previously scheduled to an earlier milestone labels Aug 31, 2020
@RyanCavanaugh RyanCavanaugh added the Rescheduled This issue was previously scheduled to an earlier milestone label Dec 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug A bug in TypeScript Fix Available A PR has been opened for this issue Rescheduled This issue was previously scheduled to an earlier milestone
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants