text:
Unable to resolve self-reference imports in js files

Bug Report
It does not seem to be possible (that I can tell) to get typescript to understand a self-reference import in a .js file which is being checked, e.g. due to the presence of a // @ts-check comment.
🔎 Search Terms
Self-reference import js @ts-check
🕗 Version & Regression Information
Version: 4.7.0-dev.20220424
💻 Code
js-self-ref-test/package.json:
{
  "name": "js-self-ref-test",
  "exports": {
    ".": {
      "default": "./lib/index.js",
      "types": "./lib/index.d.ts"
    }
  },
  "devDependencies": {
    "typescript": "^4.7.0-dev.20220424"
  },
}

tsconfig.json:
{
  "compilerOptions": {
    "module": "commonjs",
    "rootDir": ".",
    "moduleResolution": "nodenext"
  }
}

test.js:
// @ts-check
import 'js-self-ref-test'; // Cannot find module 'js-self-ref-test' or its corresponding type declarations. ts(2307)

🙁 Actual behavior
Cannot find module 'js-self-ref-test' or its corresponding type declarations. ts(2307)
🙂 Expected behavior
No error

Your JS file isn’t included by that tsconfig.json, so it’s just getting default settings from your editor, which doesn’t include --moduleResolution nodenext which is the thing that makes this work. If you add allowJs: true, I think it should start working.

Thank you, it works!


text:
Promise intersection with primitive results in wrong awaited type

Bug Report
When we make an intersection of a promise with a primitive type like Promise<T> & T (where T is primitive (non-object)), the resulting type from await (Promise<T> & T) is wrong (still contains a promise). This is clearly a bug since Awaited<Promise<T> & T> and (Promise<T> & T).then(x => {}) behave correctly (the result is only T). The issue is only observed when using the await keyword.
The types arrangement might seem arbitrary, but it has a valid use case which is provided in the playground link below.
🔎 Search Terms
PROMISE & PRIMITIVE, PROMISE INTERSECTION, AWAITED TYPE, INCONSITENT THEN AND AWAIT
🕗 Version & Regression Information

Tested only versions available on playground!

This changed between versions 4.5.5 and 4.7.0-dev.20220503. 4.4.4 and lower are unaffected by this bug.

⏯ Playground Link
Playground link with relevant code
💻 Code
type A = Promise<number> & number;
const a = {} as A;

const b = await a;
type B = typeof b; // B should be "number", but it is "Promise<number> & number"!

a.then((c) => {
  type C = typeof c; // C is "number" (which is corrent)
});

type D = Awaited // D is "number" (which is corrent)

🙁 Actual behavior
Type B still contains Promise<number> despite of the value being awaited.
🙂 Expected behavior
In the example above B has to be equal to C and D.

https://github.com/microsoft/TypeScript/pull/45350 this is probably related. However, as shown before, the Awaited itself works correctly.

I don’t understand (even with your playground example) why you would ever write Promise<number> & number.  This type represents a value that is simultaneously both a promise and a primitive number, which is impossible.

The code in there seems to be using symbol, but there are no values which are both symbols and promise objects.  Could you clearly articulate the use case in words?
Even better, could you show a working example of your use case at runtime? Your playground link uses {} as the runtime value which won't actually work at runtime.  Like, forget the TS types for a bit, what kind of JS behavior are you trying to support?

It does seem theoretically wrong, but yeah, unless there is a real-world use case I doubt we’ll prioritize a change here.

I don't think this would be a hard fix - at the moment this is somewhat explicitly called out to be invalid in one of the comments:
https://github.dev/microsoft/TypeScript/blob/8f56f6b49d2fb282ff95df64f62dab2947004e95/src/compiler/checker.ts#L36317-L36321
Probably one of the required changes to make this work would be to tweak the related logic in the getPromisedTypeOfPromise here:
https://github.dev/microsoft/TypeScript/blob/8f56f6b49d2fb282ff95df64f62dab2947004e95/src/compiler/checker.ts#L36265-L36268
I could take a stab at this - if only somebody would confirm that this behavior needs to be adjusted. I also don't see though how this could be utilized in the real-world code so far.

I did a quick experiment monkeypatching String.prototype.then to see if it would be called by Promise.resolve (or await, which uses the algorithm of the former). It did not. It’s pretty hard to follow but I think I found this in the spec: https://tc39.es/ecma262/#sec-promise-resolve-functions

If Type(resolution) is not Object, then
a. Perform FulfillPromise(promise, resolution).
b. Return undefined.

The only way I can interpret string & Promise<string> is a value that is definitely the primitive string but also manages to satisfy the Promise interface structurally, which perhaps you could do with a horrifying regimen of monkeypatching. The spec and my experiment seem to agree that such a value (the stuff of nightmares) would in fact emerge unchanged from await. So the type is correct.

Thank you all for your feedback.
@andrewbranch I don't think this issue should be closed. I just made a full example use case which roughly replicates what I'm trying to achieve in my project. I'm working on a custom asynchronous store for Svelte similar to this one or this one. The idea behind it is to abstract away API interactions, so the store can manage everything. To achieve that I'm using a data structure which I call RichPromise which is basically Promise<T> & T of anything (including primitives). This is achieved by constructing a special prototype chain which includes the original object's prototype, bound methods for primitives, overrides such things as [Symbol.toPrimitive] and valueOf, and adds then, catch, finally to mimic a promise behavior (for implementation details see enrich function in the example). Because the original prototype is included in RichPromise's chain enrich(Promise.resolve("2"), "1") instanceof String is true.
This has one caveat though. When we first look at out rich promise (before any api calls resolve), there is no data to be concatenated with a promise, so we pair it with loading symbol placeholder. This way the type becomes Promise<T> & (T | typeof loading). I choose to use a symbol, so we can infer the loading state by type with if (richPromise == loading) which works because of the [Symbol.toPrimitive] override. So, it is must have for primitive types to work correctly because the guard above only works if we use unique symbol, but not Symbol which makes sense. However as we do not have unique Symbol as an object there is no other way to solve it.
This whole approach was chosen to elegantly support 2 different rendering strategies in svelte templates:

  {#if $store != loading}
    {$store}
  {:else}

    Loading
  {/if}

  {#await $store}

    Loading
  {:then data}
    {data}
  {/await}

In the linked example I'm trying to mimic something similar to svelte stores without the framework. If you run the code, you'll see the showcases of the two strategies shown above:
Showcase loading strategy 1
Loading...
(3) ['super', 'important', 'data'] 'Data: super important data'
(3) ['super', 'important', 'data'] 'Data: super important data'
(3) ['some', 'changed', 'data'] 'Data: some changed data'

Showcase loading strategy 2
Loading...
(3) ['super', 'important', 'data'] 'Data: super important data'
(3) ['super', 'important', 'data'] 'Data: super important data'
Loading...
(3) ['some', 'changed', 'data'] 'Data: some changed data'
(3) ['some', 'changed', 'data'] 'Data: some changed data'

Note that in a real scenario the same data would not be rendered twice.
Anyway besides all of that, this is INCONSISTENCY (between then, await, Awaited) and should be considered a bug. Moreover, since this was introduced just recently it cannot be seen an intended behavior.

Also, if we had a way to
data: A | B;
if (data != B) {
  data: A;
}

where B extends object. That would also solve my particular use case. But I would rather get the original issue solved for the sake of consistency.
If anyone knows if the snippet above is achievable (without changing an operator or using a function) please let me know.

Fun fact
I also tried to use document.all and %GetUndetectable() for prototyping a falsy object to a promise, so this would be possible:
{#if $store}
  {$store}
{:else}
  Loading
{/if}

{#await $store}
  Loading
{:then data}
  {data}
{/await}

But it was a little bit to far... And there were some problems with promises not being detected since typeof document.all returns undefined and not an object. So I decided to go ahead with the symbol approach.

And even ignoring everything considered, it just makes sense for await Promise<number> & number to return number. Regardless of if anybody is going to use it or not...

@andrewbranch Yeah... I think you are right after all. I did use an Object(<value>) wrapper when constructing my promises. So the types are actually a String and not a string. And I even think I'm fine with that even how it works now.
But what I actually want is to have unique Symbol or rather  unique object in general. So we can narrow based on equality to singleton objects.
const singleton = {} as unique Record<string, any>;

const unknown = {a: "test"} as {a: string} | typeof singleton.

if (unknown != singleton) {
  unknown: {a: "test"};
  unknown.a; //test
}

If there's already a way to do this in the language, please let me know. If not, I'll open a feature request then.

unique object sounds like nominal typing: see e.g. https://github.com/microsoft/TypeScript/issues/202

source: gharchive/issue

authors: Andarist Azarattum andrewbranch fatcerberus jcalz

repo: microsoft/TypeScript

license_type: permissive

license_source: github-api


text:
Support Array.fromAsync in lib.esnext.d.ts

Array.fromAsync recently reached stage 3 (conditional on editor review). That means we should look into implementing it in TS under esnext.
The signature should probably be
interface ArrayConstructor {
    fromAsync<T>(iterator: AsyncIteratable<T>): Promise<T[]>;

    fromAsync<T, U>(iterator: AsyncIteratable<T>, mapFn: (value: T) => U, thisArg?: any): Promise<Awaited<T>[]>;
}

The signature should probably be

These should be async iterables not iterators. Also it should probably accept sync iterables as well:
interface ArrayConstructor {
    fromAsync<T>(iterable: AsyncIterable<T> | Iterable<T>): Promise<T[]>;

    fromAsync<T, U>(
        iterable: AsyncIterable<T> | Iterable<T>,
        mapFn: (value: T) => U,
        thisArg?: any,
    ): Promise<Awaited<T>[]>;
}

Also it should probably accept sync iterables as well:

Oh and ArrayLike's as well.

Awaited[]

This behaviour is wrong for async iterables (though it does work like this for sync iterables), although TS is also wrong here with for-await-of anyway:

class CustomAsyncIterator<T> implements AsyncIterableIterator<T> {
    readonly #iterator: Iterator<T>;

    constructor(values: Iterable<T>) {
        this.#iterator = values[Symbol.iterator]();
    }

    async next(): Promise<IteratorResult<T>> {
        const res = this.#iterator.next();
        if (res.done) {
            return { done: true, value: undefined };
        }
        return res;
    }

    [Symbol.asyncIterator]() {
        return this;
    }
}

async function main() {
    const iter = new CustomAsyncIterator([Promise.resolve(1), Promise.resolve(2)]);

    for await (const item of iter) {
        // TS infers item is "number" but it's actually still Promise<number>
        console.log(item);
    }
}

main();

Fixed to at least do the Iterator -> Iterable portion.
A few things about that

ArrayLike probably makes sense over Array

I think it would be PromiseLike, not Promise

I don't think we need to intersperse Promise or PromiseLike at all - in theory, Awaited should take care of each element type anyway, right?

The behavior of whether the map function receives an Awaited type seems to rely entirely on whether it received an array-like value! Won't that mean that the following will differ when Iterator.from gets implemented?
// [1]
Array.fromAsync([Promise.resolve(1)])

// [Promise(1)]
Array.fromAsync(Iterator.from([Promise.resolve(1)]))

I think it would be PromiseLike, not Promise

Yes.

I don't think we need to intersperse Promise or PromiseLike at all - in theory, Awaited should take care of each element type anyway, right?

The behavior of whether the map function receives an Awaited type seems to rely entirely on whether it received an array-like value! Won't that mean that the following will differ when Iterator.from gets implemented?

Array.fromAsync has for-await-of semantics for async and sync iterables, and sync-iterable-like behaviour for array likes. This is most easily demonstrated with an example:
/**
  * Just a helper to convert an array or such to an async iterable iterator
  */
function adaptSyncIterable<T>(iterable: Iterable<T>): AsyncIterableIterator<T> {
    const iterator = iterable[Symbol.iterator]();

    return {
        [Symbol.asyncIterator]() {
            return this;
        },
        async next() {
            return iterator.next();
        }
    }
}

// case : AsyncIterable<Promise<T>> WITHOUT mapperFn
// prints [Promise { 1 }, Promise { 2 }]
// Promises ARE NOT unwrapped
console.log(await Array.fromAsync(
    adaptSyncIterable([Promise.resolve(1), Promise.resolve(2)]),
));

// case : Iterable<Promise<T>> WITHOUT mapperFn
// prints [1, 2]
// Promises ARE unwrapped
console.log(await Array.fromAsync(
    [Promise.resolve(1), Promise.resolve(2)],
));

// case : ArrayLike<Promise<T>> WITHOUT mapperFn
// prints [1, 2]
// Promises ARE unwrapped
console.log(await Array.fromAsync(
    {
        length: 2,
        0: Promise.resolve(1),
        1: Promise.resolve(2),
    },
));

// -- For all cases of mapperFn the return value of the mapperFn is unconditionally awaited

// case : AsyncIterable<Promise<T>> WITH mapperFn
// prints [[Promise { 1 }], [Promise { 2 }]]
// Promises ARE NOT unwrapped before passed to callback
console.log(await Array.fromAsync(
    adaptSyncIterable([Promise.resolve(1), Promise.resolve(2)]),
    (x) => [x],
));

// case : Iterable<Promise<T>> WITH mapperFn
// prints [[1], [2]]
// Promises ARE unwrapped before passed to callback
console.log(await Array.fromAsync(
    [Promise.resolve(1), Promise.resolve(2)],
    (x) => [x],
));

// case : ArrayLike<Promise<T>> WITH mapperFn
// prints [[1], [2]]
// Promises ARE unwrapped before passed to callback
console.log(await Array.fromAsync(
    {
        length: 2,
        0: Promise.resolve(1),
        1: Promise.resolve(2),
    },
    (x) => [x],
))

Essentially fromAsync is roughly implemented like:
function fromAsync(iterableOrArrayLike, mapperFn) {
    const items = [];
    if (Symbol.asyncIterator in iterableOrArrayLike
    || Symbol.iterator in iterableOrArrayLike) {
        for await (const item of iterableOrArrayLike) {
            if (mapperFn) {
                items.push(await mapperFn(item));
            } else {
                items.push(item);
            }
        }
    } else {
        const length = iterableOrArrayLike.length;
        for (let i = 0; i < length; i++) {
            const item = await iterableOrArraylike[i];
            if (mapperFn) {
                items.push(await mapperFn(item));
            } else {
                items.push(item);
            }
        }
    }
}

As overloads the type is essentially:
interface ArrayConstructor {
    // no unwrapping of promises
    fromAsync<T>(asyncIterable: AsyncIterable<T>): Promise<Array<T>>;
    // unwrapping of promises
    fromAsync<T>(iterableOrArrayLike: Iterable<T> | ArrayLike<T>): Promise<Array<Awaited<T>>>;

    // no unwrapping of promises passed to callback
    // but callback promise is unwrapped
    fromAsync<T, U>(
        asyncIterable: AsyncIterable<T>,
        mapperFn: (value: T) => U,
        thisArg?: any,
    ): Promise<Array<Awaited<U>>>;
    // unwrapping on both sides
    fromAsync<T, U>(
        iterableOrArrayLike: Iterable<T> | ArrayLike<T>,
        mapperFn: (value: Awaited<T>) => U,
        thisArg?: any,
    ): Promise<Array<Awaited<U>>>;
}

What's the current status of this issue? I just tried to use Array.fromAsync in a typescript project, and get the following error from ts: Property 'fromAsync' does not exist on type 'ArrayConstructor'.ts(2339)
Is it still unsupported? If so, what's the best workaround?

Would be nice to follow up on this, it's a nice interface

authors: AnthonyDugarte DanielRosenwasser Jamesernator ianconsolata


text:
Error in ESM about no extensionless imports does not occur for import with only specifier

Bug Report
Doing import "./other"; will not raise a Relative import paths need explicit file extensions in EcmaScript imports when '--moduleResolution' is 'node16' or 'nodenext'. Did you mean './other.mjs'? error.
🔎 Search Terms
import specifier only side effects
🕗 Version & Regression Information
5.0.0-dev.20230110
⏯ Playground Link
Here's a repo: https://github.com/dsherret/tsc-issues/tree/importOnlySpecifier
💻 Code
{
  "compilerOptions": {
    "moduleResolution": "NodeNext",
    "target": "ESNext",
    "module": "NodeNext",
    "declaration": true,
    "emitDeclarationOnly": true,
    "traceResolution": true
  }
}

// main.mts
import "./other";

// other.mts
export class Test {}

🙁 Actual behavior
Does not error unless I change the import to have a default, namespace, or named import. Output will fail at runtime.
======== Resolving module './other' from 'V:/tsc-issues/main.mts'. ========
Explicitly specified module resolution kind: 'NodeNext'.
Resolving in ESM mode with conditions 'node', 'import', 'types'.
Loading module as file / folder, candidate module location 'V:/tsc-issues/other', target file types: TypeScript, JavaScript, Declaration.
Directory 'V:/tsc-issues/other' does not exist, skipping all lookups in it.
======== Module name './other' was not resolved. ========
File 'V:/tsc-issues/node_modules/typescript/lib/package.json' does not exist.
Found 'package.json' at 'V:/tsc-issues/node_modules/typescript/package.json'.
File 'V:/tsc-issues/node_modules/typescript/lib/package.json' does not exist according to earlier cached lookups.
File 'V:/tsc-issues/node_modules/typescript/package.json' exists according to earlier cached lookups.
...etc...

🙂 Expected behavior
Should error because no extension used.

Side-effect imports like this have never been checked that they resolve whatsoever. @DanielRosenwasser and I briefly discussed whether we could change this, but I don’t know if there was a consensus. It would definitely be a breaking change.

Interesting. Well overall it's not really that big of a deal since people will get an immediate error when running the code and people rarely write these kind of imports.

Duplicate of https://github.com/microsoft/TypeScript/issues/50394

Yeah, I should have search for "side-effects" 😅

Added some new discussion in #50394

authors: andrewbranch dsherret


text:
Icons are completely messed up in Visual Studio member list

🔎 Search Terms
icon
icon completion
🕗 Version & Regression Information
VS 17.10.0 P6
⏯ Playground Link
No response
💻 Code
No response
🙁 Actual behavior
Icon of Properties is displayed for Parameters:

Sometimes it works:

Icon of Parameters is displayed for Classes/Interfaces:

Icon of Parameters is displayed for Local Variables:

🙂 Expected behavior
Correct icons are displayed in the member list.
Additional information about the issue
No response

One more case:
Icon of Properties is displayed for Functions (among completions):

While the correct icon is displayed in quick info:

Hello @Peter-Juhasz! Given that this issue is specific to Visual Studio's completion, could you please move this discussion to a new issue in https://developercommunity.visualstudio.com/VisualStudio? Thank you!

Hi @MariaSolOs,
I reported the issue here for the following reasons:

Since Visual Studio provides only the hosting and presentation, it is controlled by the language service what to display. In this case, it is the responsibility of the TypeScript language service to choose the correct icons what Visual Studio should display. The same way, if there is an issue only with TypeScript in VSCode, the issue won't belong to the VS Code repo I guess, but here. And on the videos I've provided you can clearly see that it works very differently in different settings. So, my assumption was that the issue is with the TypeScript language service, it selects the icons incorrectly for the completions items to display in same cases (while it works correctly for the quick info), and not with Visual Studio.
The language service is implemented in this repo, and I have found many similar issues related to completion and tracked here.
I had a very bad experience with the VS reporting earlier, even when detailed reproduction, recordings are provided, they are closing them blindly usually with "not enough info" and that's it.

If you are confident that the issue is with Visual Studio, could you route it to the appropriate team, please? You can provide much more insider details than me, even if it slips only on the integration of the language service and VS. Thank you.

Hi Peter!
Both Maria and I work in the team that provides TypeScript and JavaScript experiences in VS. I'm sorry we haven't provided the level of answers you expected before, we try our best.
We know where the issue is here, and we would prefer to be tracking in the right systems. If you can create an issue in developer community for this and copy the link here, I'll make sure it gets immediately routed to us. Just copying and pasting this should be fine, you did an awesome job in explaining what the issue is.
Thanks!
J

authors: MariaSolOs Peter-Juhasz joj


text:
Nominal unique type brands

Fixes #202
Fixes #4895
We've talked about this on and off for the last three years, and it was a major reason we chose to use unique symbol for the individual-symbol-type, since we wanted to reuse the operator for a nominal tag later. What this PR allows:
type NormalizedPath = unique string;
type AbsolutePath = unique string;
type NormalizedAbsolutePath = NormalizedPath & AbsolutePath;

declare function isNormalizedPath(x: string): x is NormalizedPath;
declare function isAbsolutePath(x: string): x is AbsolutePath;
declare function consumeNormalizedAbsolutePath(x: NormalizedAbsolutePath): void;

const p = "/a/b/c";
if (isNormalizedPath(p)) {
    if (isAbsolutePath(p)) {
        consumeNormalizedAbsolutePath(p);
    }
}

unique T (where T is any type) is allowed in any position a type is allowed, and nominally tags T with a marker that makes only T's that have come from that location be assignable to the resulting type.
This is done by adding a new NominalBrand type flag, which is a type with no structure which is unique to each symbol it is manufactured from. This is then mixed into the argument type to unique type via intersection, which is what produces all useful relationships. (The brand can have an alias if it is directly constructed via type MyBrand = unique unknown)
This does so much with so little - this reduces the jankiness written into types to enable nominalness with unique symbols or enums, while adding zero new assignability rules.
So, why bring this up now? I was thinking about how "brands" work today, with something like type MyBrand<T> = T & {[myuniquesym]: void} where T could then become a literal type like "a". We've wanted, for awhile, to be able to more eagerly reduce an intersection of an object literal and a primitive to never (to make subtype reduction and intersection reduction produce less jank and recognize more types as mutually exclusive), but these "brand" patterns keep stopping us. (Heck, we use em internally.) Well, if we ever want to change object types to actually mean object, then we're going to need to provide an alternative for the brand pattern, and ideally that alternative needs to be available for awhile. So looking on the horizon to breaks we could take into 4.0 in 9 months, this simplification of branding would be up there, provided we've had the migration path available for awhile. So I'm trying to get the conversation started on this before we're too close to that deadline to plan something like that. Plus #202 is up there on our list of all-time most requested issues, and while we've always been open to it, we've never put forward a proposal of our own - well, here one is.
On unique symbol
unique symbol's current behavior takes priority for syntactically exactly unique symbol, however if a nominal subclass of symbols is actually desired, one can write unique (symbol) to get a nominally branded symbol type instead (or symbol & unique unknown - it's exactly the same thing). The way a unique symbol behaves is like a symbol that is locked to a specific declaration, and has special abilities when it comes to narrowing and control flow because of that. Nominally branded types are more flexible in their usage but do not have the strong control-flow linkage with a host statement that unique symbols do (in fact, they don't necessarily assume a value exists at all), so there is very much reason for them to coexist. They're similar enough, that I'm pretty comfortable sharing syntax between the two.
Alternative considerations
While I've used the unique type operator here, like we've oft spoken of, on implementation, it's become plain to me that I don't need to specify an argument to unique. We could just expose unique as a unique type factory on it's own, and dispense with the indirection. The "uniqueness" we apply internally isn't actually tied to the input type argument through anything more than an intersection type, so simply shortening unique unknown to unique and reserving the argument form for just unique symbols may be preferable. All the same patterns would be possible, one would just need to write string & unique instead of unique string, thus dispensing with the sugar. It depends on the perceived complexity, I think. However, despite being exactly the same, string & unique is somehow uglier and harder to look at than unique string, which is why I've kept it around for now. It's probably worth discussing, though.
What this draft would still need to be completed:

[ ] New error messages for any errors involving brands (One or more unique brands is missing from type A with related information pointing at the brand location, rather than the current error involving unique unknown)
[ ] More tests exercising indexed access and exploring how indexed accesses on branded types are constructed (specifically, what should be done if you (attempt to) index nothing but a union of unique unknown brands)
[ ] Tests for unique (symbol) declaration emit (to ensure it's not rewritten as unique symbol)
[ ] Discussion on if keyof <unique brand type> should be never (as it is now), since the brand is top-ish (and contains no structure information itself), or if it should be preserved as an abstract keyof <unique brand> type, so that brand can apply keys-of-branded-types constraints in constraint positions
[ ] 🚲 🏠

While I've used the unique type operator here, like we've oft spoken of, on implementation, it's become plain to me that I don't need to specify an argument to unique.

I don't understand this part.  If these are meant to replace branded types, then:
type UString = unique string;
type BString = string & { __brand: true };

declare let ustr: UString;
declare let bstr: BString;
let str1: string = bstr;  // ok because branded string is a subtype of string (this is generally desirable).
let str2: string = ustr;  // could be ok because unique string is also a string.
let num: number = ustr;  // never ok, should be error because unique string is NOT a number!

But if we just had unique without the argument, there would be no way to make this distinction.  unique would just end up being a nominal unknown (effectively an opaque Skolem constant) which doesn't sound that useful to me?

But if we just had unique without the argument, there would be no way to make this distinction.

It's useful because you can then intersect it with something. Which is all unique string is doing under the hood right now - making that intersection for you.

Yeah, I need to read more closely.  I just noticed the string & unique bit before you posted.  But I don't like this because unique by itself isn't a type.  It would be a special marker that doesn't work by itself as a type (or at least, doesn't make sense as one - what would it mean to take an argument of form arg: unique, e.g.), which I find very weird to then use in a position that nominally (no pun intended!) accepts only type operands.  I guess there's precedent with ThisType<T>, but... I don't know, it rubs me the wrong way.

unique is essentially ust shorthand for unique unknown under the current model, and it does function fully as a standalone type.

Is this proposal allows to assign literals to variable/param which has branded type?
type UserId = unique string
function foo(param: UserId) {}

foo("foo") // ok
var x: UserId = "foo"; // ok

const s = "str";
var y: UserId = s; // not ok
foo(s) // not ok

How would you make nominal classes with this?

Not easily. You'd need to mix a distinct nominal brand into every class declaration, like via a property you don't use of type unique unknown or similar, and then ensure that your inheritance trees always override such a field (so a parent and child don't appear nominally identical).
I'd avoid it, if possible, tbh. Nominal classes sound like a pain :P

Is this proposal allows to assign literals to variable/param which has branded type?

Branded types can only be "made" either via cast or typeguard, as I said in the OP, so no. This is because the typesystem doesn't know what invariants a given brand is meant to maintain, and can't implicitly know if some literal satisfies them.

Would something like the following ever be meaningful?
interface Parent extends unique { }
interface ChildA extends (Parent & unique) { }
interface ChildB extends (Parent & unique) { }

This is probably obvious to everyone but unique T shouldn't replace branding.
There are scenarios where branding is the only viable solution (at the moment).
For example,
//Can be replaced with `unique number`
type LessThan256 = number & { __rangeLt : 256 }
//Cannot be replaced with `unique number`
type LessThan<N extends number> = number & { __rangeLt : N }

More complicated example here,
https://github.com/microsoft/TypeScript/issues/15480#issuecomment-513105767

There are a few reasons why I'm generally against the idea of unique T.
(And nominal typing, and instanceof, and using symbols)
Cross-library interop
Library A may have type Radian = unique number.
Library B may have type Radian = unique number.
Both types will be considered different, even though they have the same name and declaration.
If libraries start using this unique T all over the place, you'll start needing unsafe casts (as libA.Radian) more often. This means you can accidentally write myDegree as libA.Radian and cast incorrectly. Whoops!
So, one starts thinking that a no-op casting function would be safer,
function libARadianToLibBRadian (rad : libA.Radian) : libB.Radian {
  return rad as libB.Radian;
}

This is safer because you won't accidentally convert myDegree:libA.Degree to libB.Radian
But if you have N libraries with their own Radian type, you may end up needing up to N^2 functions to convert between each of the Radian types from each library.

Cross-version interop
It's happened to me a bunch where I've had the same package, but at different versions, within a single project.
So,
v1.0.0's type Radian = unique number would be considered different from,
v1.1.0's type Radian = unique number
Now you need a casting function... Even though it's the same package.

With brands, if two libraries use the same brands, even if they're different types, they'll still be assignable to each other. (As long as they don't use unique symbol)
Library A may have type Rad = number & { __isRadian : void }.
Library B may have type Radian = number & { __isRadian : void }.
Even though they're different types, they're assignable to each other. No casting needed.
v1.0.0 and v1.1.0 of type Rad and type Radian will work with each other fine.

Re: nominal classes - classes are already nominal if they contain any private members.  Just throwing that out there. :smiley:

So we can finally have things like this?
// Low-end refinement type :)
type NonEmptyArray<A> = unique ReadonlyArray<A>
function isNonEmpty(a: ReadonlyArray<A>): a is NonEmptyArray<A> {
    return a.length > 0
}

@fatcerberus It's also why I avoid classes entirely and avoid private members if I do have them =P

Hmm...
const normalizedPathBrand = Symbol();
const absolutePathBrand = Symbol();

type NormalizedPath = string & typeof normalizedPathBrand;
type AbsolutePath = string & typeof absolutePathBrand;
type NormalizedAbsolutePath = NormalizedPath & AbsolutePath;

declare function isNormalizedPath(x: string): x is NormalizedPath;
declare function isAbsolutePath(x: string): x is AbsolutePath;
declare function consumeNormalizedAbsolutePath(x: NormalizedAbsolutePath): void;

const p = "/a/b/c";
consumeNormalizedAbsolutePath(p); //Error
if (isNormalizedPath(p)) {
    consumeNormalizedAbsolutePath(p); //Error
    if (isAbsolutePath(p)) {
        consumeNormalizedAbsolutePath(p); //OK
    }
}

Playground

If cross version compatibility really is an issue then an alternate solution would be to make naming explicit:
Let the type unknown "name" denote the set of all values with label name. This would make the intersection type approach mandatory so a nominal path must now be written:
type NormalizedPathOne = string & unique "NormalizedPath";

where an unlabelled unique denotes a generative type as defined in the OP.
type NormalizedPathTwo = string & unique // some label that we don't care about that is auto-generated.

so while two declarations of NormalizedPathTwo produce distinct types, two declarations of NormalizedPathOne produce identical types.
FWIW I have no real preference---for me the big win of this feature is being able reduce empty intersections more aggressively.

Discussion on if keyof unique brand type ....

IMO, for all brand oblivious operations a unique type should be equivalent to unknown (which is what is proposed).

I've implemented Opaque types like so:
type Opaque<V> = V & { readonly __opq__: unique symbol };

type AccountNumber = Opaque<number>;
type AccountBalance = Opaque<number>;

function createAccountNumber (): AccountNumber {
    return 2 as AccountNumber;
}

function getMoneyForAccount (accountNumber: AccountNumber): AccountBalance {
    return 4 as AccountBalance;
}

getMoneyForAccount(100); // -> error

@AnyhowStep I know, but that's how I'm currently creating opaque types. I hope this Pull Request will incorporate this into the language, and make it even better than my implementation.

Nominal types are pretty useful. The example I often use is the APIs that take latitude/longitude and bugs that are result of mixing up latitude with longitude which are both numbers. By making those unique types we can avoid that class of bugs.
However, unique types can cause so much pain when you have to keep importing those types to simply use an API. So I'm hoping that at least primitive types are assignable to unique primitives where I can still call my functions like this:
// lib.ts
export type Lat = unique number;
export type Lng = unique number;
export function distance(lat: Lat, lng: Lng): number;

// usage.ts
import { distance } from 'lib.ts';
distance(1234, 5678); // no need to asset types

As @AnyhowStep mentioned cross-lib and cross-version conflicting unique types can also be a source of pain. Can we limit uniqueness scope somehow? Would that be a viable solution?

https://github.com/microsoft/TypeScript/pull/33290 is now open as well, so we can have a real conversation on what the non-nominal explicit tag would look like, and if we'd prefer it.

BTW, this is now a dueling features type situation (though I've authored both) - we won't accept both a #33290 style brand and this PR's style brand, only one of the two (and we're leaning towards #33290 on initial discussion). We'll get to debating it within the team hopefully during our next design meeting (next friday), but y'all should express ideas, preferences, and reasoning therefore within both PRs.

@typescript-bot pack this

@weswigham Only the authors of pr can @typescript-bot?

Only repo contributors have permission to request that @typescript-bot pack this

How should I write a unique type constructor?
type integer = unique number
function isInteger(a: number) { return a === (a | 0) }

function Interger (a:number): integer{
    if(!isInteger(a)) throw new Error("not integer");
    return a // Error: Type 'number' is not assignable to type 'integer'. \n Type 'number' is not assignable to type 'unique unknown'.
}

@xiaoxiangmoe I think you should add a type guard:
function isInteger(a: number): a is integer { return return a === (a | 0) }

Borrowing from an example from the other PR...
Let's say I want to have a unique UserId type that is also tagged with details about its composition. What would be the correct way to combine these types into a final unique version?
type NonEmptyString = unique string;
type Uuid = unique string;

// Oops, these two are probably assignable to each other!
type GroupId = NonEmptyString & Uuid;
type UserId = NonEmptyString & Uuid;

I downloaded the tgz build and tried these out, which both appear to "work" on a surface level...
type GroupId = unique (NonEmptyString & Uuid);
type UserId = unique (NonEmptyString & Uuid);

type GroupId = unique string & NonEmptyString & Uuid;
type UserId = unique string & NonEmptyString & Uuid;

@ProdigySim yep, the way you'd accomplish that is with extra unique tags for each unique thing you want to track.

How would one go about using phantom type params to get unique nominal types with this PR? Is there a way?
For example:
type User = ...
type Organization = ...

Key<A> = unique string

type UserId = Key<User>
type OrganizationId = Key<Organization>

The goal of the above would be to make sure UserId and OrganizationId aren't interchangeable, but the generic type param does not influence the structure of the runtime type at all. Would the above just work? Or would you need to do something like:
Key<A> = unique string & A

or something else?

How would one go about using phantom type params to get unique nominal types with this PR? Is there a way?

As is, nope. A unique tag is unique per declaration site, and every instantiation gets the same unique brand, irrespective of type parameters. You'd need to do something like type Key<A> = unique string & A, except you probably want to stash A somewhere it's value can't be observed (like in a property). The phantom type use-case of the structural brands we have today isn't handled well by this proposal.

@weswigham I just saw your other PR using tag which does support phantom types. That looks interesting.
Just out of curiosity, would it be possible to add a keyword solely for this purpose to be used in tandem with this implementation?
Maybe, something like:
type Key<A> = unique string & phantom A

or
type Key<A> = unique string & tagged A

or something like that, where phantom or tagged essentially behave similarly to unique, uniquely modifying the nominal type, but without any false/ghost properties added to the structural type.
Alternatively, maybe using unique as a prefix to a type alias would implicitly do something just like the above? like:
// the leading `unique` automatically affects the nominal type under the hood
unique type Key<A> = unique string

I'm not familiar with all this rhetoric, bit isn't having phantom types the goal, as they're actually unique types? Theyre without any __mysterious_props__ (and weird compiler errors).

Will unique
Currently, the best I can think of for declaration file emit for:
// example.ts
export class A {
     #foo: number;
}

is:
// example.d.ts
export declare class A {
    #foo;
}

But this violates the spirit of hash private fields: users shouldn't have to scroll past like 50 implementation details in order to see the stuff that matters to them.
If we can emit unique that would preserve the nominality and hide the implementation better:
// example.d.ts
export declare unique class A {}

@weswigham Thanks for doing this work and creating this proposal! The unique approach is a much better fit for my requirements than the tag proposal. :D
Just out of curiosity, have you and/or the team considered having unique be a "declaration transformer" rather than a "type transformer"?
E.g.
unique type Foo = string;
// Rather than `type Foo = unique string;`

unique interface Bar {
  field: string;
}

unique class Baz {
  constructor(
    public field: string,
  ) {}
}

Assuming that your underlying brand intersection implementation can stay the same, I can't help but notice that a "declaration transformer" approach seems to have several advantages over the "type transformer" approach:

It opens up the possibility of nominal interfaces and classes (which several people have already asked about)
It's syntactically closer to the prior art of Flow's opaque types (opaque type Foo = string;, IIRC)
It more clearly distinguishes between nominal types and unique symbols (which, as you've said, are meaningfully different, and I subjectively don't believe that using parens for that case is intuitive)

If you guys have looked at this approach and decided against it, could you elaborate as to why?

@treybrisbane That is also the syntax I would most like, I think... especially if it automatically made any type params present affect the nominal type, even if they were phantom type params.
unique type Key<A> = string
In the above, every unique A, regardless of whether or not it gets used in the right side of the type definition, would result in a unique nominal type.
I don't know how doable this is, and, perhaps, it would need to be implemented as a structural type hack under the hood, but it would be nice to be able to support phantom types like this without requiring the user to think about structural types (like the tag in the other PR, or similar).
This might be hard/not possible. Not sure. Just thinking out loud.

Is there any progress on this feature?

I like this proposal more than the other one. This is more explicit and less verbose. I understand the concerns raised here, but I think they should be considered features, and this should be used carefully by the community. I understand this is not always the case, and people could start using and misusing this for everything, but this is as for all the features that Typescript introduces. They are not always used as intended.
One particularly seems to be a good example of why this proposal is good for me.
Cross-library interop
Library A may have type Radian = unique number.
Library B may have type Radian = unique number.
And they are different. Libary A can update is definition tomorrow to type Radian = bigint, and that would be ok. I understand that if I have two nominal types, that both are numbers, seems wrong that they can't assign each other, but is that what this is about? Having someway to declare a unique type?
If I can declare a unique type that can be assigned to a different unique type because they have the same shape, are they unique then?

This PR leads to the Tower of Babel problem more easily, because of cross-library interop.

@AnyhowStep

But if you have N libraries with their own Radian type, you may end up needing up to N^2 functions to convert between each of the Radian types from each library.

You don't have to create N^2 converting functions, just one. In Haskell, Conor McBride's newtype library uses over and the like to allow conversion between newtypes. Now, we don't have typeclasses, but we could still do something similar here:
const coerce: <A, B>(a: unique A) => IfEquals(A, B, unique B, never)
  = (a) => a as any

Where the IfEquals function is taken from here. We could also use as ReturnType<typeof coerce> instead of as any but it makes no difference here. Now you can convert between any uniques that share the same underlying type:
coerce<libA.Radian, libB.Radian>(foo)

coerce<,>(), foo as libB.Radian, and the N^2 conversion functions are all unsafe, of course.
However, the N^2 explicit functions is "safer" because more effort had to go into creating them.
Having a coerce<,>() function is much closer to the as operator, and is more "unsafe" because it lowers the barrier to casting types.
That's my personal opinion, anyway.

To what extent does https://github.com/microsoft/TypeScript/issues/31894 satisfy the same requirements as this proposal?  I know @DanielRosenwasser mentioned in https://github.com/microsoft/TypeScript/issues/38510 that while nominal brands would be nice, but that it's not clear whether it's counter to the goals of 4.0 at the moment.
That said, it seems to me that one could easily enough write
placeholder type NormalizedPathBrand;
placeholder type AbsolutePathBrand;
type NormalizedPath = string & NormalizedPathBrand;
type AbsolutePath = string & AbsolutePathBrand;

where the brands are module-local and never intended to be implemented by any concrete type.  Branded types already need explicit casts to instantiate them, so it's easy enough to make them.  Given that that proposal seems to have more traction, does it make this one obsolete?

Is there a status update on this PR?

@weswigham Couple questions:

Could you elaborate further on how unique symbol and unique (symbol) differ with respect to control flow-sensitive typing? I would've thought neither would have special behavior on that front.
Do you have any status update for this? It's been over a year with pretty much radio silence.

Could you elaborate further on how unique symbol and unique (symbol) differ with respect to control flow-sensitive typing? I would've thought neither would have special behavior on that front.

unique symbol is a single runtime value. Specifically, the result of an invocation of Symbol() at some location. Because of this, it works as a well-known property name, and acts as a literal. Each place unique symbol is written is a distinct, single symbol. unique (symbol) is "a unique subset of all symbols" and represents an abstract set of potentially multiple symbols. This behaves differently - notably, it isn't usable as well-known property name.

Do you have any status update for this? It's been over a year with pretty much radio silence.

Oh, wow, it's been that long. Uh. Last time I presented it to the team, the response was somewhat lukewarm - there's no real excitement or drive for it right now. So I guess what we're looking to see is overwhelming demand?

So I guess what we're looking to see is overwhelming demand?

Not sure how the demand is properly measured, just saying that this PR is in top 5 upvoted open PRs at them moment 😁

@weswigham Thanks for the quick explanation! I see why both are necessary, now. Also, I definitely recommend looking into @kachkaev's comment above.

Just used branding to very quickly identify the inconsistencies in a code base that was using string for 3 different logical dynamically valued types. Consider this my +1...

Just used branding to very quickly identify the inconsistencies in a code base that was using string for 3 different logical dynamically valued types. Consider this my +1...

Just a bit of data: The last codebase I was in changed from using unique symbol to string-based tag types due to their simplicity in creating compatible types across repos.
We wanted to move to an code generation system for our web API types. We had backend code that used nominal types ("tinytypes") in Scala which was the source of our branding.
Using unique-symbol based types had a couple of drawbacks here:

We would need to have every nominal type exposed on the API to be predefined somewhere in TypeScript
If the backend & frontend nominal type names mismatched at all, we would need to write custom mapping.
One potential solution would be to have a shared library with all our "global" nominal types. But, this opens the possibility for "Dreaded Diamond" dependency patterns on these types, which would lead to incompatible nominal types (different "unique symbols" from different versions of the library)

We ended up converting all of our nominal types to string-based tag types overnight to support this project. They solved all of these problems:

API code gen can just emit a generic Opaque<T, 'tag'> and not worry about references/imports
If backend and frontend nomenclature mismatch, we can negotiate on the value of the 'tag' string, without any user-facing implications.
Don't need a shared library in this solution. If we did opt for one, the dreaded diamond would not be an issue unless the type tags actually changed--which would probably mark an important compatibility change.

tl;dr string-based tag types seem a little more flexible with implementation details and are still good enough. They still have the hard problem of naming things, but they are fixable when there are name conflicts. We can also put out recommendations for tag patterns in shared libraries.

This experiment is pretty old, so I'm going to close it to reduce the number of open PRs.

Will there be any type of these unique/opaque types or how ever these are called be added into typescript itself?
I needed something like that in a project where I had to juggle like a couple of simple "number" IDs and here something like unique number type per ID would've helped to save some time debugging :D

Is there a particular reason this experiment stalled out?

@sandersn IMO this is a very valuable feature. Nominal types can greatly increase type safety and I would imagine they could also greatly improve compiler performance by skipping structural comparisons. IMO this should not be summarily closed simply because it hasn't had attention recently.
This is the 9th most voted on PR in the entire repo, I  think that's a clear indicator that a lot of people want it and it's probably worth pushing forward. Would you please reopen it?
@weswigham since you authored this, do you think it is worth continuing the work you started or should this be closed in favor of a new discussion/implementation?

I mean, personally, I think the structural version of this PR, the tag types PR, is the more general and better one. You can make those tags into nominal ones by including a unique symbol in your tag type, but conversely you can't make these into a structural tag, and structural tags have a lot of nice properties for interface merging and cross-library tag type management.

@weswigham I'm not familiar with the PR you're referring to, would you link to it please?

#33290

Thanks, I agree that PR seems like it is a better approach. Unfortunately it looks like that one got summarily closed as well. Given that there seems to be a lot of interest in support for some form of nominal typing perhaps it should be reopened?

From the last comment on the other PR:

This is effectively an implementation sketch for https://github.com/microsoft/TypeScript/issues/202. We'd prefer people interact with the suggestion issues than the PRs, since the implementation of a feature is mechanical once the design has been worked out, and nominal types are still very much under discussion

@weswigham Hey great man, how was this going?

source: gharchive/pull-request

authors: AnyhowStep ProdigySim Shou alex-weej be5invis cevek evelant fatcerberus goodmind isiahmeadows jack-williams joshburgess kachkaev mheiber michaeljota mohsen1 negue raveclassic resynth1943 ruojianll sandersn shicks treybrisbane weswigham xiaoxiangmoe


text:
Add missed resolveSymbol in commonjs import resolution

Fixes resolution of export aliases in the postfix-property-access case
of commonjs require:
const { x } = require('./foo').nested
x

This program would previously fail if x was an export alias.
Fixes #41422

Yep, there are a set of Functions You Should Call on all resolved symbols, and they're not at all enforced.

@typescript-bot cherry pick this to release-4.1
Open to hearing reasons why this isn’t a strong candidate to backport to a patch release, but the fix seems simple and innocuous and the bug seems pretty bad if you hit it, though I don’t expect to many people will. But at least one did: #41629

@typescript-bot cherry-pick this to release-4.1
Does cherry-pick have to be hyphenated?

authors: andrewbranch sandersn


text:
Add JSDoc's @inheritDoc Support for Static Class Members for TypeScript

Fixes #23215

#23215 is kind of old, and it leaves a lot of questions underspecified.

Is @inheritDoc required for inheritance? jsdoc.app says no.
Are other tags allowed? jsdoc.app doesn't give an example with other tags, so maybe not.
Are comments allowed? jsdoc.app also doesn't give an example with a comment on the derived method.
If other tags are allowed, how are they integrated? The current method seems to combine the base and derived tags all together, which doesn't make sense for param tags; the parameter names might be the same, or they might be different.
If the parameter names are the same, or if both base and derived have return tags, should the inherited tags replace the old one? Probably yes.
Is the case of the tag important? Probably no.
Why does this only work on static members?

Answering the inheritance questions seems like a lot of work. If I were writing this, I'd be very tempted to say that (1) the derived jsdoc must have @inheritdoc (2) the derived jsdoc must have no other tags or comments.

@Zzzen Do you want to keep working on this? Otherwise I'd like to close it to reduce the number of open PRs.

Thanks for reminding me. And yes, I'm going to finish it.

jsdoc.app says that it is provided for compatibility with Closure Compiler, which is written in java. Haven't check the source code of Closure Compiler, I think they should work like javadoc.

Inherits (copies) documentation from the "nearest" inheritable class or implementable interface into the current doc comment at this tag's location. This allows you to write more general comments higher up the inheritance tree, and to write around the copied text.
This tag is valid only in these places in a doc comment:

In the main description block of a method. In this case, the main description is copied from a class or interface up the hierarchy.
In the text arguments of the @return, @param and @throws tags of a method. In this case, the tag text is copied from the corresponding tag up the hierarchy.

See Automatic Copying of Method Comments for a more precise description of how comments are found in the inheritance hierarchy. Note that if this tag is missing, the comment is or is not automatically inherited according to rules described in that section.

authors: Zzzen sandersn


text:
Updating WSL broke the installation

Windows Version
Microsoft Windows [Version 10.0.22631.3007]
WSL Version
2.0.14.0
Are you using WSL 1 or WSL 2?

[X] WSL 2
[ ] WSL 1

Kernel Version
5.15.133.1-1
Distro Version
Ubuntu 22.04
Other Software
No response
Repro Steps
I am not sure that these steps will reproduce the error as I can't test it anymore

Ran wsl.exe --update from PowerShell. I had temporary admin rights when I ran this command
Run WSL after update, some errors reported on terminal but things were running correctly and errors no longer produced in subsequent terminals. (did not bother to log these errors unfortunately)
Restart computer with admin rights disabled.
WSL does not start

Expected Behavior
WSL starts correctly after update
Actual Behavior
Failed to attach disk 'C:\Program Files\WSL\system.vhd' to WSL2: The system cannot find the file specified.
Error code: Wsl/Service/CreateInstance/CreateVm/MountVhd/HCS/ERROR_FILE_NOT_FOUND

[process exited with code 4294967295 (0xffffffff)]
You can now close this terminal with Ctrl+D, or press Enter to restart.

Diagnostic Logs
I checked the registry for this key:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Lxss and the versions there are older than the ones I get in the terminal using wsl.exe --version .
Registry vs Terminal Versions:
(Default)               REG_SZ      (value not set)
GraphicsVersion         REG_SZ      1.0.27          ==> 1.0.59 (terminal)
KernelVersion           REG_SZ      5.10.102.1      ==> 5.15.133.1-1 (terminal)
NatGatewaylpAddress     REG_SZ      192.168.48.1
NatNetwork              REG_SZ      192.168.48.0/20
RollbackKernelVersion   REG_SZ      5.10.16
SystemDistro            REG_SZ      C:\ProgramData\Microsoft\WSL\system.vhd
VirtioFsClassld         REG_SZ      {DF380B4F-9282-46B6-AAAB-E94BDD7EC5BB}

Copying the file system.vhd from C:\ProgramData\Microsoft\WSL\system.vhd to C:\Program Files\WSL\system.vhd allows WSL to start again normally but I feel like this is a really dirty solution and I don't know what will happen when I update again.

Can't Install WSL - Tried All Fixes Posted Here (#3504),  similarity score: 0.87

It seems like this issue is similar to mine but I have provided more information than the other, I feel like the other could be closed.
All the rest are not the same

WSL broke after Windows update (#10831),  similarity score: 0.87
wsl install fail (#4747),  similarity score: 0.86
WSL stopped working now reinstall failing (#10760),  similarity score: 0.86
Cannot install WSL  (#8054),  similarity score: 0.86

I followed the steps here to solve the issue. Once I completely uninstalled WSL,
I installed Ubuntu 22.04 again from the store, upgraded through the terminal from 2.0.9.0 to 2.0.14.0 and a similar error occurred, WSL was not able to find the system.vhd file.
I uninstalled completely again, installed through the terminal using wsl --install, updated again and the error didn't appear

Closing since the issue is resolved.

@OneBlue I don't think reinstalling the kernel from scratch without understanding why it happens can be considered a solution to close the issue

@OneBlue same issue here after updating to 2.0.14
please reopen this is not solved, that is a hacky workaround

authors: OneBlue erSitzt hhalaby

repo: microsoft/WSL

license: MIT


text:
E: Unable to locate package wsl

Windows Build Number
Microsoft Windows [Version 10.0.19041.985]
WSL Version

[X] WSL 2
[ ] WSL 1

Kernel Version
Invalid command line option: --status
Distro Version
Ubuntu 20.04 LTS
Other Software
No response
Repro Steps
sudo apt install wsl
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package wsl
Expected Behavior
Install WSL, I did update and upgrade
Actual Behavior
WSL not working properly
Diagnostic Logs
No response

A. did you sudo apt update first?
B. Are you looking for the right thing? wsl the apt package is WSMan Shell not Windows Subsystem for Linux
Apt is not managed by Microsoft. If you're looking for help with WSMan Shell, this is not that.

authors: SheepReaper yonasuriv


text:
can't access my distribution on win11

Version
Microsoft Windows [版本 10.0.22000.593]
WSL Version

[X] WSL 2
[ ] WSL 1

Kernel Version
5.10.16
Distro Version
Ubuntu-18.04
Other Software
No response
Repro Steps
I am the administer of the computer.

版本	Windows 11 家庭中文版
版本	21H2
安装日期	2022/2/10
操作系统版本	22000.593
体验	Windows 功能体验包 1000.22000.593.0

There is a vEthernet that I can not disabled.

Expected Behavior
I have successfully installed and run my Ubuntu using wsl and used Buildozer to package an app for Android.
I just want to use wsl and windows exploer to access linux correctly.
Actual Behavior
In cmd or power shell, I can use "wsl -l -v" to see my distribution.

NAME            STATE           VERSION

Ubuntu-18.04    Stopped         2

but I can not open it, when I use "wsl", it displays

{应用程序错误}
应用程序发生异常 s (0x

which means "{application error} application went wrong s(0x".
In windows exploer, it still does not work.

which means "can't access. You may not have the permission to use the internet resources. Please to communicate with the administer..."
Diagnostic Logs
No response

/logs

authors: OneBlue hemomona


text:
Wana an EXE or MSI installer for WinDbg-Preview

I want to install WinDbg-Preview on Windows Server 2019, which has no Store Environment. Provide EXE or MSI installer would be a good idea.

We are actively investigating non-Store alternatives to installing WinDbg-Preview and we'll update this issue when we have an update.

Do you have an update for this? Would be excellent for creating base images.

One other option - which doesn't run any installers, is to download the msixbundle and unzip. I wrote a PowerShell script to help with that, see my comment on a related issue.

The Store install is not the latest anymore and fails for some people. The download from "https://aka.ms/windbg/download" runs but then fails with a generic "Access Denied" error. ARG!!!! I guess packaged installations have issues and policies. Fortunately the Powershell script works. Thank you for that Uzybkr. THANK YOU! But yes, please, for the love of mental sanity, make a simple install available, or better, a portable downloadable version that does not require installation.

微软这些人真的是SB,appinstaller显示没网,应用商店打不开,你他妈的就给个exe文件会死

repo: microsoft/WinDbg-Samples


text:
Sample builds OK but won't run

App freshly cloned
Windows SDK 1809 installed

F5/Ctrl-F5:
Build has been canceled.DEP6957:

Failed to connect to device '127.0.0.1' using Universal Authentication.
Please verify the correct remote authentication mode is specified in the project debug settings.
COMException - No connection could be made because the target machine actively refused it.
(Exception from HRESULT: 0x8007274D) [0x8007274D]

Closing issue due to age. Please open a new issue if required.

authors: Karl-Bridge-Microsoft yannduran

repo: microsoft/Windows-appsample-rssreader


text:
Feature for sharing security descriptors (take 2)

This resurrects #209 , rather than attempt to re-merge an extremely old branch when so much has changed, I've created a new PR here.
The two major requests on the old PR, which are both addressed here, were to get the WinRT API coded up, and to make sure we hand out a self-relative security descriptor.
After coding up the tests for the WinRT API, I'm having some doubts about the WinRT version taking an array of name/mask structs. This pattern makes it much harder to avoid creating hstrings on the heap, and I wouldn't have thought it commonplace for callers to specify multiple app container names at a time. I'll probably change the WinRT API to take a single app container name and access mask, so as not to defeat helpers like C++/WinRT's param::hstring helper. I'd like to get some thoughts from people like @jonwis , @BenJKuhn , and @mikebattista, and @DrusTheAxe. Also, any thoughts on if this should be marked preview/experimental (with velocity)?

I'm having some doubts about the WinRT version taking an array of name/mask structs... I'll probably change the WinRT API to take a single app container name and access mask

If so please update the API spec and code for review. If not, please remove this from the comment as it won't reflect the comment.

any thoughts on if this should be marked preview/experimental (with velocity)?

Is this feature committed and expected in 1.1? If so then you don't need to tag anything.
A release cycle has Experimental release(s) (i.e. whatever's in main) and towards the latter part of the cycle sees Preview release(s) and then ultimately the Stable release. Experimental marking and Velocity'izing implementation is only relevant if a feature is experimental when we have Preview and Stable releases, as that marking+Velocity is how we 'strip' the experimental bits from a release.
If you're not committed for 1.1 then yes, you need to mark+Velocity.
If you're unsure you could wait a bit until Preview|Stable gets closer and worst case mark+Velocity for that. It's easy enough to add if/when needed. OTOH you could mark+Velocity now, and later when Preview|Stable rolls around if you're not experimental  you could remove the mark+Velocity bits. Deferred-optimization vs proactive-implementation, whichever fits best fits your case :-)

/azp run

/azp run

authors: DefaultRyan DrusTheAxe

repo: microsoft/WindowsAppSDK


text:
Update Microsoft.WindowsAppRuntime.Bootstrap.Net.csproj

A microsoft employee must use /azp run to validate using the pipelines below.
WARNING:
Comments made by azure-pipelines bot maybe inaccurate.
Please see pipeline link to verify that the build is being ran.
For status checks on the develop branch, please use TransportPackage-Foundation-PR
(https://microsoft.visualstudio.com/ProjectReunion/_build?definitionId=81063&_a=summary)
and run the build against your PR branch with the default parameters.
For status checks on the main branch, please use microsoft.ProjectReunion
(https://dev.azure.com/ms/ProjectReunion/_build?definitionId=391&_a=summary)
and run the build against your PR branch with the default parameters.

I think we don't need this any more.


text:
_CompileToDalvikWithDx "java" exited with code 2

What App Center service does this affect?
Build
Describe the bug
When building on Android I receive the following error :

"/Users/vsts/agent/2.154.3/work/1/s/Client/.Android/.Android.csproj" (PackageForAndroid target) (1) ->
(_CompileToDalvikWithDx target) ->
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.targets(2721,3): error MSB6006: "java" exited with code 2. [/Users/vsts/agent/2.154.3/work/1/s/Client/.Android/.Android.csproj]

This issue is AppCenter only and does not replicate on my local machine.
To Reproduce
Create an Android project targeting monodroid9.

Might be this issue: https://docs.microsoft.com/en-us/xamarin/xamarin-forms/troubleshooting/questions/maps-compiletodalvik-error

Heap size is 2G. Again, not an issue on local machines, only in AppCenter. Maybe related to recent SDK  updates? Maybe the build server needs new packages?

@NVentimiglia can you reach out directly to App Center Support so we can dig into the issue there please? Thanks!

I seem to be having a similar issue.
My app center build fails with the following error message but runs fine locally.

"/Users/vsts/agent/2.155.1/work/1/s/source/FScruiser.Droid/FScruiser.Droid.csproj" (PackageForAndroid target) (1) ->
(_CompileToDalvikWithDx target) ->
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.targets(2521,3): error MSB6006: "java" exited with code 2. [/Users/vsts/agent/2.155.1/work/1/s/source/FScruiser.Droid/FScruiser.Droid.csproj]

For the _CompileToDalvikWithDx target, I get the following output in my build log

_CompileToDalvikWithDx:
Creating directory "obj/Release/proguard".
/usr/bin/java -Xmx1G -jar /Users/vsts/Library/Android/sdk/build-tools/27.0.3/lib/dx.jar --dex --no-strict --output obj/Release/android/bin /Users/vsts/agent/2.155.1/work/1/s/source/FScruiser.Droid/obj/Release/android/bin/classes.zip ... rest of line truncated

trouble writing output: Too many field references to fit in one dex file: 66866; max is 65536.
You may try using multi-dex. If multi-dex is enabled then the list of classes for the main dex list is too large.
References by package:
29 android.app
3066 android.arch.core
8 android.arch.core.executor
14 android.arch.core.internal
3161 android.arch.lifecycle
3066 android.arch.lifecycle.livedata
3066 android.arch.lifecycle.livedata.core
3066 android.arch.lifecycle.viewmodel
34 android.content.pm
10 android.content.res
55 android.graphics
::: rest of log entry truncated :::

When I use ClassyShark to analize my localy built apk I get the following method counts from my local built apk. https://i.imgur.com/Nfm1zWD.png

@BenCamps If you go to "Project options > Build > Android Build" in VS4Mac, you should see an option "Enable multi-dex" you can activate, which is what the error message "You may try using multi-dex" is referring to. Can you give that a try?
Come to think of it, I think I do remember encountering some issues where multidex only triggered failures when running in the Build VMs but not locally, but I don't remember the exact error message. It's only the later part of the error message that really highlights that...
@NVentimiglia Might be worth taking a quick check with that as well.
I also have a sample I maintain here that uses multi-dex: https://github.com/King-of-Spades/AppCenter-Samples/tree/master/Xamarin.UITest/UITestDemo

Was able to resolve the issue. Problem was on my end. The solution was to upgrade the targeting in the environment-specific AndroidManifest

authors: BenCamps King-of-Spades NVentimiglia nrajpurkar

repo: microsoft/appcenter


text:
Microsoft.AspNetCore.Mvc.Versioning.* 4.x is not compatible with netstandard2.1

This is a breaking change for people who were using Microsoft.AspNetCore.Mvc.Versioning.* 3.* which was netsteadard2.0.
Telling people to change their .NET Standard to a .NET Core library is not really acceptable without a really good reason why. None has been given.
Was this breaking change made by accident and you could just as easily build and deploy Microsoft.AspNetCore.Mvc.Versioning.* as .NET Standard or was it on purpose and no one documented it in the breaking changes migration documents?
I see no mention of breaking changes between 2.2 and 3.1 doc and this is a breaking change between migrating between those versions as we have to stop using .NET Standard for a lot of our supporting library which kind of defeats one of the purposes of .NET Standard.
https://docs.microsoft.com/en-us/dotnet/core/compatibility/2.2-3.1

This is not a breaking change. To briefly reiterate the existing issue (#591), .NET Standard is not a target supported by ASP.NET Core 3.0+. You cannot correctly use ASP.NET Core 3.0+ libraries while targeting .NET Standard. ASP.NET Core 3.0+ can, however, consume external .NET Standard libraries. API Versioning directly references ASP.NET Core libraries, therefore, the only target framework it can support are the those matched by ASP.NET Core itself.
The confusion came from multi-target support for OData because there was no support for it on .NET Core 3.0. The choices were to leave OData behind or multi-target. I chose to multi-target because I know what had to be done, but I'm starting to wish I left it behind until it caught up. The target for OData is ASP.NET Core 2.2, which does support .NET Standard. Once OData had a suitable version on ASP.NET Core 3.0+, and hence .NET Core 3.0+, it no longer made since to multi-target so it was dropped. I have no intention, capacity, nor do I believe there are any community expectations that a single package version will support ASP.NET 2.2 and 3.0+ long-term and at the same time.
If you are trying to target .NET Standard, but you use ASP.NET Core 3.0+ libraries, including API Versioning, I don't know how to more politely say that you were doing it wrong. It's simply not supported. The reason you likely thought it was working is that NuGet resolved the wrong TFM reference. Depending on what your code does, there's a very real chance that a consumer of your package/library will encounter a nasty runtime error such as MissingMethodException.
I've gone through great lengths to explain this to library authors. Please refer to #591. If that's still unclear to you, I'll elaborate further. Apologies for the confusion. Thanks.

It actually was working 100% as the .NET Standard 2.0 library that was referencing these and being consumed by ASP.NET 2.2 projects. Its a breaking change because well it broke the build when upgrading because you took a target away and didn't list it as a breaking change in the official migration documents.  Talking about it in issues is not really the same as the official migration documents posted on docs.microsoft.com.
Therefore if people "were doing it wrong" its because Microsoft was "doing it wrong" then as well and the wrong way was working just fine.  So if it is working production code its not really wrong code.
This is the VERSIONING libraries, not the primary ASP.NET libraries. This is a supporting library I don't really see why it could not be .NET Standard 2.1.
It is what it is, and it just would be nice if it was in the several official migration documents for going from ASP.NET Core 2.x to ASP.NET Core 3.x they are very useful and the first place most of us look when something breaks during migration to find the replacement, or that is not needed anymore, or the new way of doing it.

Apologies if it sounded snooty. It was a rather heated debate in the past. Let me try to provide some additional guidance / clarification.
I agree that the documentation is not entirely clear on the migration (I reviewed it). Unfortunately, I don't own or have any engagement with those folks. It looks like the only thing they discuss on the topic is source code changes. When the documentation says breaking changes, they are referring to changes in the APIs, not the target frameworks.
Maybe an illustration will help. Here's why API Versioning cannot use .NET Standard in ASP.NET 3.0+:
Microsoft.AspNetCore.Mvc.Versioning → Microsoft.AspNetCore.Mvc.Core → .NET Core 3.0
However, in 2.2 it looked like:
Microsoft.AspNetCore.Mvc.Versioning → Microsoft.AspNetCore.Mvc.Core → .NET Standard 2.0
To summarize:

Source TFM
Target TFM
Compatibility

netstandard2.0
netcoreapp3.0
Valid

netcoreapp3.0
netstandard2.0
Invalid

Since ASP.NET Core 3.0 only targets .NET Core 3.0, then that's the only target API Versioning can offer as well. There's no way for it to go backward to .NET Standard 2.0 or 2.1.
I honestly never had the intention of supporting ASP.NET 2.2 after the API Versioning 4.0 release. The only reason it existed was for OData. I was constantly getting pushed by the community to support .NET Core 3.0. I knew there'd still be some ASP.NET 2.2 users, but it didn't really occur to me that so many would want to try and upgrade. That's certainly a failure of communication on my part and I'll own that.
My guidance to you if you need ASP.NET Core 2.2 and .NET Standard 2.0 support is to clip off API Versioning at 4.0.0. The only difference between 4.0.0 and 4.1.0 is the transition from .NET Core 3.0 to .NET Core 3.1, which has no bearing on the ASP.NET Core 2.2 build.
At least one other person has asked, but I do not intend to go back and reverse integrate features or fixes that target ASP.NET 2.2. That doesn't mean I won't though. While rare, I have gone back and fixed bugs in older versions. I run this repo by myself and I just don't have to the capacity to support maintaining both versions of ASP.NET.
I hope that helps clear things up. I'm happy to help provide additional guidance or recommendations if you need them.
Thanks

authors: CreepyGnome commonsensesoftware

repo: microsoft/aspnet-api-versioning


text:
Azure Load Test is not recognized as a trusted resource to bypass Key Vault firewall

Describe the bug
Azure Load Test can access Key Vault, only if setup to allow access from All public networks. If Key Vault chooses to limit public access to specific vnets, then Load Test can no longer fetch secrets. This is true even when the "allow trusted Microsoft services" option is selected:

To Reproduce
Steps to reproduce the behavior:

Setup two Key Vault instances - one that allows access to all public networks and one that limits access to specific vnets.
Add an access policy to both Key Vault instances to allow Secret Get - use the same managed identity in both cases.
Create a Load Testing instance. Configure the Identity as User managed and set the identity to the same added to the Key Vault access policy.
Create a test that injects a secret. I set the value to the URL of the more private Key Vault secret.
Run the test - observe that when leave the value pointiing to the more private Key Vault, it fails to start the test, but when change the value to the more public Key Vault it runs successfully.

Expected behavior
Should be able to access the more private Key Vault - either by being able to specify a vnet when creating the Load Testing instance, or by having Azure Load Testing be a "trusted Microsoft resource" that can still gain access to the Key Vault.
Screenshots
Private vs Public Key Vault. As in steps to repro, the access policies in both Key Vaults are the same, using the same identity. Then the same Load Test is used to trigger a success and a failure, varying only the URL of the Key Vault secret.

The more private Key Vault looks like this:

Additional context
Have tried with both User managed and System managed identities.
AB#1665865

Hi @cathalmchale ..currently this is not supported by the service, and we have added this to our backlog. We will report back once we implement this.

Hi @Sachid26 - any update on this feature?

Hi - Any update on this feature? Is there any work around?

Bump... Any update?

Bump... Any update?

Bump... Any update?

Bump... Any update?

Azure load testing service now supporting Azure keyvaults behind a firewall or a private virtual network.
https://learn.microsoft.com/en-nz/azure/load-testing/how-to-parameterize-load-tests#create-a-secret-in-azure-key-vault
If you restricted access to your Azure key vault by a firewall or virtual networking, follow these steps to grant access to trusted Azure services.

@Nagarjuna-Vipparthi Can we close the issue now?

Sure
On Mon, Apr 8, 2024, 10:47 Sulabh Upadhyay @.***> wrote:

@Nagarjuna-Vipparthi https://github.com/Nagarjuna-Vipparthi Can we
close the issue now?
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/azure-load-testing/issues/117#issuecomment-2043322480,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AED5OBLQQ6BYGURWCAHDFGLY4LJ27AVCNFSM6AAAAAARXEFFFSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBTGMZDENBYGA
.
You are receiving this because you commented.Message ID:
@.***>

Requested feature is now supported. Closing the issue.

authors: BlauerPulli Nagarjuna-Vipparthi Sachid26 cathalmchale denhsu ffurrer2 karkavi980 markditianquin sulabh-msft

repo: microsoft/azure-load-testing


text:
azure-webapp:deploy resource copy fails

azure-webapp-maven-plugin v1.9.1
Plugin configuration in your pom.xml
  <plugin>
      <groupId>com.microsoft.azure</groupId>
      <artifactId>azure-webapp-maven-plugin</artifactId>
      <version>1.9.1</version>
      <configuration>
          <schemaVersion>V2</schemaVersion>
          <resourceGroup>RCOS2Home</resourceGroup>
          <appName>rcos2server</appName>
          <region>centralus</region>
          <subscriptionId>07fd4bb9-6449-4c5b-b597-b50aafd1b6c5</subscriptionId>
          <authentication>
       		<serverId>azure-auth</serverId>
    	  </authentication>
          <runtime>
        		<os>linux</os>
          	<!-- for now only jre8 is supported for <javaVersion> of linux web app-->
          	<javaVersion>jre8</javaVersion>
          	<!-- <webContainer>tomcat 8.5</webContainer> -->
        	</runtime>
          <deployment>
              <resources>
                  <resource>
                   <directory>${project.basedir}/target</directory>
                   <includes>
                       <include>*.jar</include>
                   </includes>
                  </resource>
              </resources>
          </deployment>
      </configuration>
  </plugin>

Expected behavior
app.jar gets deployed to the existing Azure App Service
Actual behavior
$ mvn -ntp -DskipTests=true -B azure-webapp:deploy -Pprod
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------< com.spinmnt.rcos2:rcos-2-server >-------------------
[INFO] Building Rcos 2 Server 0.0.1-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- azure-webapp-maven-plugin:1.9.1:deploy (default-cli) @ rcos-2-server ---
[WARNING] You are using an old way of authentication which will be deprecated in future versions, please change your configurations.
[INFO] Authenticate with ServerId: azure-auth
[INFO] [Correlation ID: 245c74f1-c189-42b9-acd8-7b4fe003c6b4] Instance discovery was successful
[INFO] Updating target Web App...
[INFO] Successfully updated Web App.
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource to C:\Users\Tom\AzureDefect\RCOS2Server\target\azure-webapp\rcos2server-349b09c7-e349-4c37-9254-0e4d8395258e
[INFO] Trying to deploy artifact to rcos2server...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  14.983 s
[INFO] Finished at: 2020-08-05T12:01:50-05:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal com.microsoft.azure:azure-webapp-maven-plugin:1.9.1:deploy (default-cli) on project rcos-2-server: No executable jar found in target folder according to resource filter in , please make sure the resource filter is correct and you have built the jar. -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
Same Maven command executed with -X option:
mvn -ntp -DskipTests=true -B azure-webapp:deploy -Pprod -X
produces following snippet in console output:
...
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[DEBUG] resource with targetPath C:\Users\Tom\AzureDefect\RCOS2Server\target\azure-webapp\rcos2server-7d862ce0-9317-4ff1-9826-4c16b196ec6a
directory C:\Users\Tom\AzureDefect\RCOS2Server/target
excludes []
includes [*.jar]
[DEBUG] ignoreDelta true
[INFO] Copying 1 resource to C:\Users\Tom\AzureDefect\RCOS2Server\target\azure-webapp\rcos2server-7d862ce0-9317-4ff1-9826-4c16b196ec6a
[DEBUG] file app.jar has a filtered file extension
[DEBUG] copy C:\Users\Tom\AzureDefect\RCOS2Server\target\app.jar to C:\Users\Tom\AzureDefect\RCOS2Server\target\azure-webapp\rcos2server-7d862ce0-9317-4ff1-9826-4c16b196ec6a\app.jar
[INFO] Trying to deploy artifact to rcos2server...
I've traced the above logging output to the org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering and org.apache.maven.shared.filtering.DefaultMavenFileFilter classes. It appears the DefaultMavenResourcesFiltering.copyFile() method at line 101 fails but no error is reported
Steps to reproduce the problem
Running on Windows 10 Pro with Azure CLI installed. Have tried using Windows cmd shell and Powershell (with admin rights) and git bash shell. All produced same result. Also tried using Docker container provisioned with Ubuntu, Azure CLI, Maven and Java8 - same result.
The attached zip contains the project (executable jar) I'm trying to deploy. Edit pom.xml to change azure-webapp-maven-plugin config to appropriate azure resources. My Azure subscription was provisioned with:
Resource Group: RCOS2Home
App Service: rcos2server (linux, Java8)
App Service Plan rcos2server-plan
Application Insights: rcos2server-insights
For authentication, a service principal was created for the app and the authentication credentials added the maven settings.xml file as follows:

azure-auth

{from az ad sp rbac command output}
{from az ad sp rbac command output}
{from az ad sp rbac command output}
AZURE

Unzip the attached and build the jar with:
mvn install -DskipTests=true -Pprod
Then try to deploy with:
mvn -ntp -DskipTests=true -B azure-webapp:deploy -Pprod to reproduce.
RCOS2Server.zip

@twolfrum Thanks a lot for your report, will looking into this issue soon.

@twolfrum Could you please set  <executable> of spring-boot-maven-plugin to be false and try again? This which will generate a bash file with jar content, while maven plugin requires a jar which could be invoke by java -jar (jar with Main class in Manifest)

repo: microsoft/azure-maven-plugins


text:
check if variable execResult is defined

Task name: Universal packages
Description: Fix undefined code exception on execCode object
Documentation changes required: N
Added unit tests: (Y/N) N
Attached related issue: (Y/N) Y
https://github.com/microsoft/azure-pipelines-tasks/issues/15011
Checklist:

[ x ] Task version was bumped - please check instruction how to do it
[ x ] Checked that applied changes work as expected

/azp run

repo: microsoft/azure-pipelines-tasks


text:
Update lodash in MysqlDeploymentOnMachineGroupV1 to fix CVE-2019-10744

Fixes CVE-2019-10744

/azp run


text:
Missing YAML option to checkout submodules recursively

While it seems that the general feature to checkout submodules recursively has been added to the agent, there does not seem to be a YAML option to actually enable it. Just setting
steps:
- checkout: self
  submodules: true

does not checkout submodules recursively as can bee seen here.

https://docs.microsoft.com/en-us/azure/devops/pipelines/yaml-schema?view=azure-devops&tabs=schema#checkout
submodules: recursive

Ah, thanks! Strange how I could have overlooked that. Closing this!

While it seems that the general feature to checkout submodules recursively has been added to the agent, there does not seem to be a YAML option to actually enable it. Just setting
steps:
- checkout: self
  submodules: true

does not checkout submodules recursively as can bee seen here.

Broken link

repo: microsoft/azure-pipelines-yaml


text:
Publicly Accessible Reporting Pages Pose a Serious Threat to User Data Privacy and Security

Issue Description:
The current architecture of our application allows the reporting pages to be publicly accessible to anyone with the knowledge of a specific URL format. These URLs typically follow the format chat.azurewebsite.net/reporting/<url_unique_identifier>. Anyone with this URL can freely access these pages without an enforced security measure or authentication process. This design creates an inherent vulnerability that poses a severe threat to our user's data privacy and security.
For instance, potentially sensitive, confidential, or personally identifiable data is automatically at elevated risk of exposure, particularly in scenarios where unauthorized individuals can guess or obtain the unique identifiers required to navigate to these reports.
Practically speaking, this could mean a breach of user confidentiality, and could lead to potential misuse of data reported on these pages. Furthermore, such data breaches not only diminish our users' trust and loyalty but they can also lead to lawsuits and regulatory penalties depending on the nature of data being exposed.
To mitigate this severe security concern, we propose the following actions:

Access Control: Implement a mechanism to control access to these report pages, such as user roles and permissions-based security model.

Authentication and Authorization: Adopt a mandatory sign-in process for all users attempting to access these pages. Determine user privileges based on their roles within the organization to ensure appropriate access levels.

Public URL Flag: Make sure URLs are publicly accessible only when the Public URL access feature is flagged on for specific reports. By default, all URLs should be private and secure.

Encryption: Use encrypted SSL connections for transmission of sensitive data.

Audit Logs: Maintain a record of everyone who accesses a report, including what actions they carry out whilst there to build a clear audit trail.

We kindly request that the team prioritize this issue, considering the serious legal and reputational risks involved. Please address this concern a priority, and provide updates on the progress of resolving this issue within this thread.

@ArunkumarRamanan All pages and APIs require authentication for access, and there is an additional 'admin' flag to limit reporting access only to administrators.
Please check the 'middleware.ts' file for protected  endpoints

@ArunkumarRamanan all sub paths under /reporting are protected as part of the middleware.
https://github.com/microsoft/azurechat/blob/main/src/middleware.ts
Are you able to reproduce this issue and share in more detail? Happy to take a look and fix if required.

You've spent a lot of time telling how you want this feature to be secured, but not a lot describing what you'd like to do.  I don't see a clear ask for new functionality.  Change your prompt to specify the creation of functional requirements for a chat sharing feature.  Here is the openai FAQ for chat sharing.

OK, now modify your prompt to include your security requirements, alongside your functional requirements, point it at the files int the "\src\app" folder (making sure you don't include the favicon), and ask the LLM to write the code in typescript.  This will probably be more than 8k of context so you may need to swap to the 32k model.  Also, what about the reporting capability you mentioned that seems to be missing from the functional requirements?

authors: ArunkumarRamanan grayjeremy thivy

repo: microsoft/azurechat


text:
Sign in to Azure is stuck

Issue Type: Bug
When I want to connect my Azure AD account, I am stuck after I enter my credentials and login on Azure Login page and I don't get a successful callback to Azure Data Studio.
Azure Data Studio version: azuredatastudio 1.32.0 (4a45ba7cf20dd4129f1a08e5e776dfb33e3d1d1e, 2021-08-16T18:08:28.086Z)
OS version: Windows_NT x64 10.0.19042

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz (8 x 1992)

GPU Status
2d_canvas: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: enabledopengl: enabled_onrasterization: enabledskia_renderer: enabled_onvideo_decode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
15.75GB (2.99GB free)

Process Argv

Screen Reader
no

VM
0%

Extensions (2)

Extension
Author (truncated)
Version

schema-compare
Mic
1.11.0

sql-database-projects
Mic
0.12.0

I have the same Issue at 2 Terminal Servers (Windows Server 2019).  At the moment I have no Idea why. Because I have a lot of other Servers there this problem is not exist. I have try reinstall the Application but that not change anything.

Here some more input from my side:
After login to Azure in the Browser:

I get a loop.
Than I open the calback link in the Developer Tools.

The site load in a loop for some minutes.
Than the Connection get close.

And in the Application I can see that error.

And this in the log.

@cssuh @kburtram
Any update on this?
This has been in the backlog for a year.

Hi @preethamrajk, we are working on this now, and plan to have it in our October release.

Still having the same issue @cssuh.
Don't think this has been fixed in the latest release from yesterday.
Version: 1.40.0 (system setup)
Commit: 3fbaa3de931ef433090fe3deb8c89cba99d7952b
Date: 2022-11-11T22:47:05.361Z
VS Code: 1.67.0
Electron: 17.4.11
Chromium: 98.0.4758.141
Node.js: 16.13.0
V8: 9.8.177.14-electron.0
OS: Windows_NT x64 10.0.19042

Hi @preethamrajk, can you please share the error you're seeing?

Adding logs from
.....\azuredatastudio\logs\20221117T105753\exthost1\output_logging_20221117T105758
[Verbose]: Starting login - []
[Verbose]: Fetching token - []
[Error]: Login failed - []
[Error]: Error: socket hang up - []

@preethamrajk Can you also please share your proxy settings?

Here it is
C:\WINDOWS\system32>SET | findstr "PROXY"
HTTPS_PROXY=http://127.0.0.1:9000
HTTP_PROXY=http://127.0.0.1:9000
NO_PROXY=localhost,127.0.0.0/8,*****.com.au,*****.net.au,*.australiaeast.azmk8s.io,*.australiasoutheast.azmk8s.io, login.docker.com

You also need to whitelist the following URLs:
https://management.azure.com
https://login.microsoftonline.com
you may need to whitelist additional URLs but this can sometimes vary on a case-by-case basis - in order to verify you aren’t blocking any URLs from going through, go to Help > Toggle Developer Tools and select the Network tab.  Here you will see any URLs that are getting blocked that you may need to whitelist to successfully add your account.

Hi @cssuh
Those URLs are already whitelisted by the Network guys. As you can imagine, the whole corp network would be crippled without access to these URLs.. 😃

authors: cssuh philipphomberger preethamrajk

repo: microsoft/azuredatastudio


text:
Unable to add account in Azure data Studio

Azure Data Studio Version: 1.43.0 (user setup)
OS Version: ADS OS Version Windows_NT x64 10.0.22621
Machine OS version: Edition	Windows 11 Enterprise
Version	22H2
Installed on	2/6/2023
OS build	22621.1555
Experience	Windows Feature Experience Pack 1000.22640.1000.0

Steps to Reproduce:

After successfully installing ADS, I face issue while linking my enterprise account.
The error doesn't contain any error codes. Attaching error snapshot.
I tried disabling VPN. But the issue persists.

Appreciate of you can provide  solution.

Does this issue occur when all extensions are disabled?: Yes/No

Hi @heramb-joshi
Please try recommendation from here:
https://github.com/microsoft/azuredatastudio/wiki/Troubleshoot-Azure-Authentication-Issues#ensure-no-system-ca-certificates-are-expired

authors: cheenamalhotra heramb-joshi


text:
flexbox.css is being pulled from a bad location

The flexbox.css file manages a lot of our layout, for example allowing for scrolling and properly displaying content with the overflow settings. However it is only being pulled from https://github.com/microsoft/azuredatastudio/blob/master/src/sql/workbench/parts/editData/browser/gridParentComponent.ts#L6.
This means if  we disable the editData contribution point, the layout for notebooks & dashboard fall apart.
We need to change where we're pulling this file to some base file.

@aaomidi I thought I saw you sent a PR to fix this?

I have. I'll close the issue.

authors: aaomidi kburtram


text:
removal of ADP notebook

As requested by @cavonac
This PR removes the useless ADP notebook from the hybrid toolkit extension.

Pull Request Test Coverage Report for Build 519444923

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.001%) to 43.291%

Totals

Change from base Build 519281880:
-0.001%

Covered Lines:
24620

Relevant Lines:
52078

💛  - Coveralls

Pull Request Test Coverage Report for Build 519444923

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.001%) to 43.291%

Totals

Change from base Build 519281880:
-0.001%

Covered Lines:
24620

Relevant Lines:
52078

💛  - Coveralls

authors: coveralls smartguest


text:
API page for bc2adls tool

It is also needed to rerun the export when it fails.
So you need the status and the possibility to start the export again. But also enable the fields again.
But also you can schedule it via Power Automate or Logic App or other tooling.

This is indeed a great way to automate the calling of most important functions on the ADLSE module. If the comments are too exhaustive, we could create the API page ourselves if you could please wait for an overall into the version 20 that we are undergoing on this app.

This is indeed a great way to automate the calling of most important functions on the ADLSE module. If the comments are too exhaustive, we could create the API page ourselves if you could please wait for an overall into the version 20 that we are undergoing on this app.

No problem to add the comments you have by myself. Just comment it and I will put it in.
Maybe it take a little bit longer because of the holiday season is almost there :)

@DuttaSoumya Do I need something on this pull request?

@DuttaSoumya I have split the API Page into two pages as discussed.

Few more comments

Changed your comments.
Waldo has created the site and AJ Kaufmann has created the site of the API guidelines.


text:
Request to Move ConfigurationBotFrameworkAuthentication from Microsoft.Bot.Builder.Integration.AspNet.Core to Microsoft.Bot.Connector

Is your feature request related to a problem? Please describe.
I'm working on other cloud hosting options for a bot, and would like to use ConfigurationBotFrameworkAuthentication, but I need to bring the entire Microsoft.Bot.Builder.Integration.AspNet.Core assembly along for the ride at the moment, just for this single class, which itself it not actually bound to anything AspNety at all.
Describe the solution you'd like
Based on the above, I'm requesting this be unbundled and moved into Microsoft.Bot.Connector, where it's base class BotFrameworkAuthentication lives. I'm happy to submit a PR for this, perhaps with some guidance if needed.
Describe alternatives you've considered
Right now, I'm creating a copy of ConfigurationBotFrameworkAuthentication in my new project.
Additional context
N/A

@HiltonGiesenow  Hmmm.  Interesting request.  My assumption was that this class, and the other Configuration* classes, were in Integration due to IConfiguration.  I would not have expected them to work in Connector.  The original goal was to avoid integration specific code in the "lower" layers since most of the stack is not integration specific.  We'd need to do some research because my first question is why does it even build in Connector.

Ah ok, I see what you mean. I guess maybe it depends on whether you classify IConfiguration as an 'Integration'? At the moment, now that I look more, it means there are classes that are practically 100% duplicated, for instance ConfigurationChannelProvider and ConfigurationCredentialProvider, between Microsoft.Bot.Builder.Integration.AspNet.WebApi and Microsoft.Bot.Builder.Integration.AspNet.Core, which is probably not ideal?
If it really makes sense to split IConfiguration-dependent elements out, perhaps there should be a Microsoft.Bot.Builder.Integration?

authors: HiltonGiesenow tracyboehrer

repo: microsoft/botbuilder-dotnet