text:
[Feature Request] Resolve alias path to relative path.

Search Terms

resolve path map
Suggestion

I think, there is two way to resolve the path:

Add an option to force TS compiler transform import path in the output.
Use a plugin (which described in 3.6 plan #31639 ) to transform the path in the output.

Use Cases

I've read some rejected FEATURE REQUEST like: #10866 #9910 #5039
And there is , maybe, the official response about those request: https://github.com/microsoft/TypeScript/issues/9910#issuecomment-234729007
However that can not convince me, because of following 2 problems

Like the above issues mentioned, it doesn't transform the path aliases into the real relative paths.
This makes the output not work with Node.js because it can not find the modules by an alias path.
Although some module like module-alias, ts-alias-loader could solve this, anyway it's not elegent, and it can not solve the second problem.

If a package insides node_modules, written in TS with paths options, its alias path in *.d.ts can not be resolved. And TS compiler will throw an error because the module couldn't be resolved.

Examples

See #10866
Checklist
My suggestion meets these guidelines:

[ ] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[ ] This wouldn't change the runtime behavior of existing JavaScript code
[ ] This could be implemented without emitting different JS based on the types of the expressions
[ ] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
[ ] This feature would agree with the rest of TypeScript's Design Goals.

There's a problem: Sometimes the paths on disk during build time are not same as the paths at runtime. What should be done about it?
There are two reasonable ways to go about solving this situation.
The first is to have you always write the path to the file on disk, and provide a way for you to specify how the compile-time path should turn into a run-time path.
The second is to have you always write the run-time path, and provide a way for you to specify how run-time paths map to disk paths during compile-time.
These are roughly equivalently good; we've chosen the second one because it's easier to "get right" and plays better with ignoring unresolved modules. In either case, you end up with an enormously complex system; the complete documentation of how to control everything here is probably tens of pages.
The third path is to offer both. This is basically taking an enormously complex system and then squaring the complexity. I think it's an understatement to call this complete insanity; no one would be able to successfully reason about this.
We're always open to more options about how to be more expressive in the space of the chosen option of "always write the runtime path"; any suggestions need to be in that realm.

Well, I read a lot of threads about same issue and I generally agree that good solution could be providing rich extensions api for typescript that allows such behavior.

For me, the biggest hole with paths functionality is the complete lack of functionality around .d.ts files.
If I have a Node module written in Typescript, I can use a bundler to export it with mapped paths... but the only way I have to do the same for .d.ts files is to do some kind of awful hacky regex thing on the exported files after tsc runs.

authors: RyanCavanaugh fenying georgyfarniev icopp

repo: microsoft/TypeScript


text:
Proposal: Allow paths compilerOption without baseUrl

Related issue: https://github.com/microsoft/TypeScript/issues/28321
Search Terms
baseUrl, paths, compilerOptions
Suggestion
Do not require 'baseUrl' in compilerOptions when 'paths' is provided.
Use Cases
We want to use 'paths' for type-checking, but don't want to resolve non-module relative names:
./1.ts
import { two } from "2"

./2.ts
export const two = 3;

Examples
tsconfig
{
  "compilerOptions": {
    "paths": {
        "foo": ["../foo"]
    }
  }
}

Actual behavior of paths without baseUrl:
Error: Option 'paths' cannot be used without specifying '--baseUrl' option
Expected behavior of paths without baseUrl:

No error message
paths are resolved relative to the project directory (which I think means the same thing as "where the tsconfig is")

Checklist
My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

We have a horrifying workaround that intentionally prevents resolving bare-specifiers against the "baseUrl" whilst permitting "paths" to be used.
It involves setting an impossible directory as "baseUrl" and then prepending "paths" values with "../" to jump out of the impossible directory back up to the project root.
{
  "compilerOptions": {
    "baseUrl": "\u0000",
    "paths": {
        "foo": ["../../foo"]
    }
  }
}

... which works today and achieves the same thing as the proposed example ...
{
  "compilerOptions": {
    "paths": {
        "foo": ["../foo"]
    }
  }
}

It would be great to be able to drop this workaround.

I'm pretty confused about what's going on here (since there is no file named "foo"). Can you provide some more examples of what you'd want this to do? What is the proposed difference between what you want and just setting baseUrl to the "project root" yourself?

Thanks for taking a look @RyanCavanaugh

I'm pretty confused about what's going on here (since there is no file named "foo")

The presence of a "foo" file is not intended to be relevant to this example. We mentioned it to show that specifying compilerOptions.paths forces also specifying baseUrl.

What is the proposed difference between what you want and just setting baseUrl to the "project root" yourself

When we set baseUrl, the semantics of TS non-relative imports changes in a way that conflicts with ECMAScript semantics. We're hoping to avoid this behavior. There's a complete example below.
Desired behavior:
tsconfig:
{
  "compilerOptions": {
    "paths": {
        "foo": ["../foo"]
    }
  }
}

file systen:

foo.ts

proj

tsconfig.json
1.ts
2.ts

1.ts should error:
import two from "2" // Error: Cannot find module '2'

2.ts contents (not relevant):
export default 2;

Actual behavior when setting paths without baseUrl

all files are as described above ^^

TS Errors:
Error: Options 'paths' cannot be specified without specifying '--baseUrl' option
Actual; behavior when setting baseUrl to project root manually
tsconfig.json:
{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
        "foo": ["../foo"]
    }
  }
}

all other files are as described above ^^

Adding baseUrl changes the semantics of imports. Spefically, there is no longer an error in 1.ts after this change:
import two from "2" // no error, but we want 'Cannot find module '2', which is the behavior when 'baseUrl' is not specified

TLDR: We're hoping to be able to use 'paths' without changing how all non-relative module paths are resolved

To give a more concrete example of why fixing this is important: setting baseUrl means that every new file you add to the baseUrl location (usually ., the project root) is an opportunity to accidentally break things.
For example: your code might be doing import * as ts from 'typescript', successfully importing from node_modules/typescript. You later create a file called typescript.ts at the project root for some testing. Whoops, your existing imports of typescript are now broken.
It's ideal if the only things that can override node_modules are explicit and minimal; using paths without baseUrl is the way to do that.

@RyanCavanaugh what new info is needed? Asking because this issue has the 'Needs More Info` label.

In the meanwhile, I discovered another workaround:
{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
        "foo": ["../foo"],
        "*": ["__INVALID__/*"]
    }
  }
}

The other workaround caused some problems for me with Webstorm (and I think other tools), which didn't like having a baseUrl pointing to a nonexistent directory. (But it inspired this one, so thanks @robpalme.)

There’s one ambiguity that needs to be cleared up in order to allow dropping baseUrl. Consider two paths entries:
"foo1": ["./lib/foo"],
"foo2": ["lib/foo"]

The former value is a relative path, while the latter is an unrooted path. Currently, both of these are resolved to the same location, relative to baseUrl.
In the absence of a baseUrl, I think it’s fairly clear that the value for the foo1 mapping should be resolved relative to the tsconfig.json location, as all other relative paths in tsconfig.json are. It’s less clear what should happen with the value for the foo2 mapping. Without an explicit base, it looks like we could do a node_modules search for lib. This could be a useful feature, but is fairly asymmetrical from how resolution works with baseUrl.

There’s one ambiguity that needs to be cleared up in order to allow dropping baseUrl. Consider two paths entries:
"foo1": ["./lib/foo"],
"foo2": ["lib/foo"]

The former value is a relative path, while the latter is an unrooted path. Currently, both of these are resolved to the same location, relative to baseUrl.
In the absence of a baseUrl, I think it’s fairly clear that the value for the foo1 mapping should be resolved relative to the tsconfig.json location, as all other relative paths in tsconfig.json are. It’s less clear what should happen with the value for the foo2 mapping. Without an explicit base, it looks like we could do a node_modules search for lib. This could be a useful feature, but is fairly asymmetrical from how resolution works with baseUrl.

Thanks for looking into this. Re the foo2 example, another option is to error in such a case, so the user can fix the paths. (my two cents is) I think it's helpful to avoid new Node-specific things in a world with multiple JS runtimes.

I think it's helpful to avoid new Node-specific things in a world with multiple JS runtimes.

Good point; the framing of my question was node-specific, but I think my question still stands without making any node-specific assumptions. I shouldn’t have implied that if we see an unrooted path ("lib/foo") we would definitely do a node_modules search, but rather that this module specifier could be passed along to whatever module resolution strategy is selected, which currently would usually do a node_modules search. So I think my question is better stated: given the path map from my previous message and no baseUrl, when resolving the specifier "foo2", should the module resolver be asked to resolve "lib/foo" or "/path/to/tsconfig/directory/lib/foo"?

I think it's helpful to avoid new Node-specific things in a world with multiple JS runtimes.

Good point; the framing of my question was node-specific, but I think my question still stands without making any node-specific assumptions. I shouldn’t have implied that if we see an unrooted path ("lib/foo") we would definitely do a node_modules search, but rather that this module specifier could be passed along to whatever module resolution strategy is selected, which currently would usually do a node_modules search. So I think my question is better stated: given the path map from my previous message and no baseUrl, when resolving the specifier "foo2", should the module resolver be asked to resolve "lib/foo" or "/path/to/tsconfig/directory/lib/foo"?

Thanks for explaining, I understand better now. Fwiw I have no intuition about which behavior would be more intuitive in that case. I do like the idea of erroring, so the user can more explicitly express intent, but of course I lack the background to know what accords best with the design principles for compiler options.

I do not think it is useful for bare-specifiers in "paths" values to ever be treated as tsconfig-relative.  If the user wants that, they should use a relative specifier.
If they were instead passed to the resolver directly, it then raises the question of whether that resolution would include further path resolution.
{
  "paths": {
    "first": ["second"],
    "second": ["./foo"],
  }
}

Path resolution is a demon-haunted world of complexity.  I would strongly err towards simplicity rather than completeness, and because I don't have a use-case for bare-specifiers here, I'd suggest erroring for now (as Max said).  If someone wants the feature, it can always be added later.

Doing more than one path substitution would make circularities possible, and I can’t think of a real use for it. I think that, at least, we would not do.

I know this is being worked on, but one consideration I wanted to mention is how auto-imports are suggested.
I converted a big project into a monorepo that uses these path specifiers, and only later noticed (when I was actually writing code) that VS Code was suggesting imports like src/foo/bar because I had to specify baseUrl in any package that wanted to have paths. I can work around the unwanted suggestions by forcing the editor to use relative suggestions, but RelativePreference.Relative (what VS Code maps to here) completely ignores paths and offers imports that look like ../../../packages/something/src/some/file, which defeats the niceness of being able to use paths.
Am I correct in assuming that baseUrl not being required would then prevent those unwanted "absolute" imports from being suggested, while still letting paths be suggested?

Am I correct in assuming that baseUrl not being required would then prevent those unwanted "absolute-relative-to-baseUrl" imports from being suggested in favor of relative, while still letting imports listed explicitly paths be suggested?

Yep!

Wonderful. I hope this can make it to 4.1. If only this were in 4.0 so we could use it now... 😃

source: gharchive/issue

authors: RyanCavanaugh andrewbranch jakebailey mheiber robpalme russelldavis

license_type: permissive

license_source: github-api


text:
tsc --watch write output of latest run to file

Search Terms
watch output file errors.err error messages
Suggestion
Make an option to let tsc --watch write the output of the latest run to a file. This way you could have all current error messages in a file, say errors.err, ready to source in vim quickfix.
Use Cases
tsc --watch is already a pretty cool mini IDE, but writing its output to a file would allow for UNIX-like file-based editor integration.
Examples

run npx tsc --watch --outputErrors errors.err
when there are errors, type :cfile in vim to jump to the first error

Checklist
My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

vim doesn't support terminal panes?

If you're running bash you can easily achieve this behavior with some scripting.
This example was just hacked together:
handleTypeScriptOutput() {
    while read -r line; do
        printf "%s\n" "$line"

        if [[ "$line" == *"File change detected."* || "$line" == *"Starting compilation"* ]]; then
            if [[ -f "output.txt" ]]; then
                rm output.txt
            fi
        fi

        echo "$line" >> output.txt
    done
}

And run with:
unbuffer ./node_modules/.bin/tsc --watch > >(handleTypeScriptOutput)

This will print out the output to the console, and also write it to output.txt. On recompilation the output.txt is deleted to only see the last result.

@RyanCavanaugh I'm not sure, will dig into that.
@MartinJohns This solution works nicely. Thanks!

authors: MartinJohns RyanCavanaugh mklinik


text:
Some array methods should allow passing values of any type

Suggestion
🔍 Search Terms

Array.prototype.includes should allow passing values of any type
Array.prototype.indexOf should allow passing values of any type

✅ Viability Checklist
My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion
Perhaps we could allow passing a generic type for array methods that search for the existence of something within an array as const so the developer can choose whether they want to allow this or not (and default to the current behavior).
The same would be useful for anything trying to find a value within an array (not just includes, but also indexOf)
📃 Motivating Example
Currently, I am experiencing this:
Playground link with relevant code
const a = ['one', 'two', 'three'] as const
const isFirstThreeNumbers = (type: string): type is typeof a[number] => a.includes(type)
//                                                                                ^
// Argument of type 'string' is not assignable to parameter of type '"one" | "two" | "three"'.(2345)

isFirstThreeNumbers('four') // <-- false
isFirstThreeNumbers('three') // <-- true

We're getting a ts(2345) error because the array can only contain certain elements.
This limitation that I cannot check whether an arbitrary value exists within the array + have a type guard that stays in sync with the array.
My workaround:
const isFirstThreeNumbers = (type: string): type is typeof a[number] => a.includes(type as typeof a[number])

This is technically incorrect casting (because type could be anything), but I can't declare type as typeof a[number] because then consumers would only be allowed to pass values that are within the array values negating the usefulness of the function in the first place.
💻 Use Cases
I think the use cases are very general. My specific use case is to determine whether a certain "exercise type" is within a given array:
const exerciseTypes = ['final', 'exercise', 'instruction'] as const
const isExerciseType = (type: string): type is typeof exerciseTypes[number] =>
  // .includes *should* allow you to pass any type, but it does not :-(
  exerciseTypes.includes(type as typeof exerciseTypes[number])

See #26255 / #14520
Using type guard here is not sound due to its behavior in the false case; see https://github.com/microsoft/TypeScript/issues/26255#issuecomment-736683821

See #26255 / #14520
Using type guard here is not sound due to its behavior in the false case; see https://github.com/microsoft/TypeScript/issues/26255#issuecomment-736683821

Gotcha! Thank you for the references @RyanCavanaugh!

Gotcha! Thank you for the references @RyanCavanaugh!

authors: RyanCavanaugh kentcdodds


text:
Honor compilation target when checking JavaScript

There is a code branch for JavaScript specific checks but it doesn't honour the target defined in the compiler options. When ES3 or ES5 is being used these things should be reported as errors as well

use of arrow function
use of const and let
use of default parameter values
short hand object literal notation
...

Also, I wonder if this code path can be executed in addition to the semantic analysis instead of instead.

I think target is the wrong property here. we need something else to mean sourceVersion or something along these lines.

With #5471 we would be emit the es3 and es5 syntax of javascript input file for es6 syntax hence these are not errors any more

instead of target or sourceVersion, perhaps: standard could be used - indicating what standard the code should comply with.

It doesn't seem like anyone needs this functionality. A curated list of lint rules would suffice if otherwise.

authors: RyanCavanaugh jrieken mhegazy niieani sheetalkamat


text:
Variadic tuple assignment fail

Bug Report
🔎 Search Terms
variadic tuple bug
🕗 Version & Regression Information
The same behavior is visible from 4.2.3 through 4.8dev
although it it as only been a bug since variadic tuples.
⏯ Playground Link
Playground link with relevant code
💻 Code
// These should be OK since variadic tuples (rest can go anywhere)
// versions 4.2.3 ~ 4.8 dev.
{
    type T12 = ["^", ...(string | boolean | undefined)[], "$"]
    const t12a:T12 = ["^", "$"];        // Should not be an error
    const t12b:T12 = ["^", true, "$"];  // Should not be an error
}

🙁 Actual behavior
As shown.
🙂 Expected behavior
Not errors, because a match exists.
Additional Info
I examined the code.  checkArrayLiteral in checker.ts performs a unidirection (left to right) search only,
However, the output from createNormalizedTupleType outputs a  normalized type that can have a single tuple in the middle (like the one in the example).
That requires a bidirectional search to get the right results.
Alternatively, createNormalizedTupleType could be forced to roll up everything after the first rest into a single rest.  But such an algorithm would result in more false postives (false passes) than necessary.  So a bidirectional search is preferable.
I can provide more details if necessary.  (I even have bi-directional search code that passes all the baselines tests).   Just ask if you want it.

note from my issues scavenger hunt: this issue was extracted from https://github.com/microsoft/TypeScript/issues/49105 and the draft PR here seems to implement a fix for this

Seems to have been fixed in 5.0.4

This was fixed between 5.0.0-dev.20230218 and 5.0.0-dev.20230219, so likely in https://github.com/microsoft/TypeScript/pull/52769

@Andarist - Thank you very much for finding that!

authors: Andarist craigphicks


text:
Have a problem with constructing a type which contains an undefined as Array member. Only triggered in whole-project compile.

Bug Report

🔎 Search Terms
Array member unknown

🕗 Version & Regression Information
exist at least with 4.8.4 and 4.9.5
The bug is not reproducible in the playground, probably because if I do tsc test/current.test.ts it does not manifest, only if I do tsc.

This is the behavior in every version I tried, and I reviewed the FAQ for entries about Array

⏯ Playground Link

Playground link with relevant code
Repository with only the absolute necessary stuff to trigger the bug:
https://github.com/kode-konveyor/cdd-ts/tree/bug/angulartest
commit 93cec6b0c3f40f768f9e790cbd6349c35d9cd4bb
💻 Code

interface Options {
    opt: boolean;
};
interface Person {
    name: string
}

type GetType = (url: string, options?: Options ) => Person

type AsGetters<T extends Array<unknown>> = {
    [K in keyof T]: () => T[K]
    }
type MethodType = (...args: any[]) => any

// makes paramgetters never
type ParameterGetters<T extends MethodType> = Extract<AsGetters<Parameters<T>>, Array<()=>unknown>>

// makes (x: () => any) => x() to fail with Type 'unknown' is not assignable to type '() => any'
//    type ParameterGetters<T extends MethodType> = Extract<AsGetters<Parameters<T>>, Array<unknown>>

type paramGetters = ParameterGetters<GetType>

const options: Options = { opt: true}

const foo: paramGetters = [()=>"a", ()=>options ]
function handleRun <T extends MethodType>(
    parameterGetters: ParameterGetters<T>
): void {
    const parameters = parameterGetters.map((x: () => any) => x()) as Parameters<T>

    console.log(parameters)
}

console.log(handleRun,foo)
function bar():undefined {
    return undefined
}
const baz = () => undefined
console.log([undefined],[bar()],[baz()])

🙁 Actual behavior
The second parameter being optional triggers the behaviour of paramGetters being never.
As if Typescript would think that an array [unknown] is impossible.
mag@mag-Librem-15-v4:~/project/KodeKonveyor/cdd-ts$ tsc
test/current.test.ts:30:45 - error TS2345: Argument of type '(x: () => any) => any' is not assignable to parameter of type '(value: unknown, index: number, array: unknown[]) => any'.
  Types of parameters 'x' and 'value' are incompatible.
    Type 'unknown' is not assignable to type '() => any'.

30     const parameters = parameterGetters.map((x: () => any) => x()) as Parameters<T>
                                               ~~~~~~~~~~~~~~~~~~~~~

Found 1 error in test/current.test.ts:30

mag@mag-Librem-15-v4:~/project/KodeKonveyor/cdd-ts$ tsc test/current.test.ts
mag@mag-Librem-15-v4:~/project/KodeKonveyor/cdd-ts$

A workaround is to pretend that the array is of unknowns and not () => unknowns, but that breaks the conversion code.
There are similar problems with the alternative implementation:
type AsGetters<T extends any[], converted extends any[] =[]> = T extends [infer head, ... infer tail]
    ? AsGetters<tail, [... converted, () => head]>
    : converted

export type ParameterGetters<T extends MethodType> = AsGetters<Parameters<T>>

🙂 Expected behavior
No error.

This behavior follows from the definitions of the types and the settings you've provided.
tsc and tsc foo.ts actually have quite different behavior since the latter will not use the settings in the local tsconfig.json. Seeing a difference between these two commands is expected if there is a local tsconfig with any non-default settings.

The problem is not that only a whole project compile triggers it. That part is a bit more complex: it cannot be reproduced in playground ot vscode.
But anyway, I have just added this information to help with reproducing the bug.
The bug is that there is an error where there should not have been one.
Please remove the "Working as Intended" label, as it is misleading.

That part is a bit more complex: it cannot be reproduced in playground ot vscode.

The error is correct if and only if you have strict null checks enabled. Your Playground link disables strictNullChecks, which is the only reason it doesn't repro there. That's the same reason you saw a difference between tsc and tsc foo.ts.
I don't see a demonstration of a bug here. 100% of this behavior follows from the type definitions and settings being provided to tsc in each case.

authors: RyanCavanaugh magwas


text:
Type narrowing with union types create impossible case with else statement

🔎 Search Terms
else
type narrowing
🕗 Version & Regression Information

This is the behavior in every version available on the typescript playground, and the FAQ doesn't seem to mention it

⏯ Playground Link
https://www.typescriptlang.org/play/?ts=5.4.5#code/C4TwDgpgBAQgrgcygXigbwFBW1AhgLigHIAeZIgGixwCNCA7OAWxogCcMBfKAH3WuwFiAPnJUcUAMYNmrDpwwYA9EqgATAPYQAzvSLAoAdw1sA1gH4MkjfW0HgO4IXhJUmCUNJiBUOlABMXBgAlgBmUAAUDnYAdLgoqF5EAJT8Eiq+UBAAHsF22nj0alJSuPT0GsA+1rYaADYQMXUaCFGOMTTJ1Tba9Y3NrdHAMZJd3BB12tDuOBnB9FC9TNCSuFMFwAAW7NB5eFAARNZMYLhseTZ4YJBnBXD08w70wME2uHUHWWxsJlBhUABJKDANggYEaKQaE5naBDOI+DL0CDBLbsEq-GhZXJ2KDbNjQCAANwgCy2GkQm32TDgONYInIhWKqPxoRMKyg1JxOTyVQkNV6DSaLTasU63VqgoGIuGoyCylUNDg9k2e2MZm0GFC90kL0uQ38UWciFSM2w-yicQSxDIKTSEhw-L6QsGHS6EnGk2mPj5PSdUplbpwCk4QA
💻 Code
type Bug = {
    a: '<=',
    b: number
} | {
    a: '>=',
    c: number
}

// doesn't work?
const test: Bug = {
    a: '<=',
    b: 2
}
if (test.a == '<=') {
    // b exists and c cannot
    console.log(test.b)
    console.log(test.c)
} else {
    // in some cases there is a "comparison appears unintentional" error if I try to compare test.a
    // neither c or b exist here even though a must be '>=' and therefore c must exist
    console.log(test.b)
    console.log(test.c)
}

// but this works
function test2(t: Bug) {
    if (t.a == '<=') {
        console.log(t.b)
    } else {
        console.log(t.c)
    }
}

🙁 Actual behavior
else statement does not type narrow properly in some cases.
In my code it's impossible to get around this as the type narrowing DOES work properly in further if statements, which prevents me from simply checking with the same comparison again with a return statement.

The example given uses the value of a to determine whether to use b or c, but the narrowing doesn't allow any code in the else to use either.
🙂 Expected behavior
The type narrowing checks for the if condition inside the else block should also apply to other code in the else block.
Additional information about the issue

Not a bug.  Types are narrowed on assignment, so TS knows it's impossible for that else to execute and test gets narrowed to never.  Hence the error message

Property 'c' does not exist on type 'never'.

Oh, I've provided a bad example here. It still happens when the value is not known (in a function) for me in some places
It seems to happen when there are nested type unions?
https://www.typescriptlang.org/play/?#code/C4TwDgpgBAKgFgSwHYHMA8MB8UC8UDeAUFCVAPZgBcUA5AIY1QA+tARjcaQG7UyEC+zApxIVqNAMaMWNACYdSULgEZeIpQCY1gljCEwA2gF0A3IUIAzAK5IJwBGSRRgEAM7AAFBLIAbKwFskV2p8JTo-CF5EVDQkANYIACchd0TkFGwWG1kIC2QIWSE4nx8ofmMASmouMgRCokULMmSvR3cCMIiy8gsobz9A1wrhRUUEXo8ucKtoZHc6WwgyXoBBRMS6EGGG0d2Aej3nRFcoBBO8pAh1RUEIH1dZidBIZc6Z3DwaMlYAKwg7RgAMkBb2gAEI8MUfNtrrtThMphEAHQUD60KTMFiImYosBouQ0GFw4lQA5HM6nc75WEk0G4mkk7EQJEqBnEpksjRs0i3e7QHa0xRk4AnADWSDIAHcThzURIFuQkD4QFAErQGEIaOxubtxlBJtNmaicJ8MUwsYbcfj5MMmTrRmTWFZgEpKVB3AgSlAJS6chcCvbFByuPb+AzeQ94fqmVAId6rCUiYKyal0kV4kl7XbiWGbgIgA
type Thing<T> = {
    op: 'a' | 'b'
    v: T
} | {
    op: 'c' | 'd'
    v1: T
    v2: T
} | T | T[];

function test(columns: { value: Thing<number | string> | undefined | null }[]): void {
    for (const { value } of columns) {
        if (value instanceof Array) {
            // this is fine
        } else if (typeof value == 'object' && value != null) {
            if (value.op == 'c' || value.op == 'd') {
                // this is fine
                value.op
                value.v1
                value.v2
            } else {
                // ts knows value.op can only be 'a' | 'b'
                if (value.op == 'c' || value.op == 'd') value
                // but v is still not defined
                value.v
            }
        } else if (value != null) {
            // string | number
            value
        }
    }
}

The simplest form looks like this:
type Thing<T> =
    | { op: 'a', a: T }
    | { op: 'c' | 'd', cd: T };

function test(value: Thing<number | string>): void {
    if (value.op === 'c' || value.op === 'd') {
        // this is fine
        value.op
        value.cd
    } else {
        // ts knows value.op can only be 'a'
        value.op
        //    ^?
        // but no a property
        value.a
    }
}

This is a duplicate of #31404 but I'll ping some folks to take another bite at the apple; maybe it's more tractable these days

Ah, so it's just the union-typed discriminant that's throwing it off?  I figured it was because value was typed as <discriminated union> | T | T[] | null | undefined that it wasn't triggering the discriminated union checks.

The TL;DR is that from the control flow analyzer's perspective, the code looks like this
type Thing<T> =
    | { op: 'a', a: T }
    | { op: 'c' | 'd', cd: T };

function test(value: Thing<number | string>): void {
    if (value.op === 'c') {
        // this is fine
        value.op
        value.cd
    } else if (value.op === 'd') {
        // this is fine
        value.op
        value.cd
    } else {
        // ts knows value.op can only be 'a'
        value.op
        //    ^?
        // but no a property
        value.a
    }
}

By exclusion, value.op went from the total possible union 'a' | 'c' | 'd' to a, but the object union itself couldn't undergo any narrowing because there's never a distinct point at which we can remove { op: 'c' | 'd', cd: T } from the list of possible inhabitants of value

authors: RyanCavanaugh fatcerberus spsquared


text:
Make methods on generators non-enumerable if possible

Fixes #50263

Per https://github.com/microsoft/TypeScript/issues/50263#issuecomment-1289486583, I think this can be closed.

source: gharchive/pull-request

authors: jakebailey magic-akari


text:
Improve checking of in operator

This PR improves checking of the in operator:

In the expression key in obj, we now require the type of key to be assignable to string | number | symbol. Previously we allowed key to be of an unconstrained type parameter type.
In the expression key in obj, we now require the type of obj to be assignable to object. Previously we allowed obj to be of an unconstrained generic type (which might be a primitive type, causing an exception to be thrown at runtime).
In control flow analysis, an expression key in obj, where key is of a string literal, numeric literal, or unique symbol type, narrows obj as follows:

If key names a property that exists in some constituent of the type of obj, the type of obj is narrowed based on the presence or absence of that property. Previously we only did this for string literal keys.
If key names a property that doesn't exist in any constituent of the type of obj, the type of obj is narrowed by intersecting with Record<typeof key, unknown>. Previously we did nothing in this case.

Some examples:
const sym = Symbol();

function f1(x: unknown) {
    if (x && typeof x === "object" && "a" in x && 1 in x && sym in x) {
        x;  // Record<"a", unknown> & Record<1, unknown> & Record<typeof sym, unknown>
        x.a;  // Ok
        x[1];  // Ok
        x[sym];  // Ok
    }
}

function f2(x: { a: string } | { b: string }) {
    if ("a" in x) {
        x;  // { a: string }
    }
    else if ("b" in x) {
        x;  // { b: string }
    }
    else {
        x;  // never
    }
}

I'm marking this PR as fixing #21732 even though it doesn't address the case of key in obj where key is of some generic type. In general, when key is of some non-finite type (like string), the only effect we can meaningfully reflect following a key in obj check is that obj[key] should be a valid expression (of type unknown), provided key and obj are both known not to have been modified since the check. This might be possible to do in the true branch of an if statement or a ternary operator, but it isn't possible in all control flow scenarios.
This PR is a breaking change because of the more accurate checking of the in operands and the more consistent narrowing of the right hand operand in control flow analysis.
Fixes #21732.
Fixes #50639.

@typescript-bot test this
@typescript-bot user test this inline
@typescript-bot run dt
@typescript-bot perf test faster
@typescript-bot test top100

Hi,
I see that you opened this PR even though #46403 is waiting to be merged - is this an improvement over that PR? In that case I'd be glad to close my PR in favor of a better solution...

@marekdedic Sorry, I didn't originally notice the existing PR. Yes, I'd say this one is an improvement in that it tightens the checking of the individual operands (e.g. disallowing unconstrained generic types), it removes dubious exceptions for this types and differences between object types and equivalent intersections types, and it ensures better caching of equivalent types by using instantiations of Record<K, T> instead of creating anonymous types on the fly. Still, I appreciate the work and time you put into your PR. I'll see if I can perhaps reuse some of your tests.

The user code test suite has two changes: One is a better error message, the other is an error that goes away because we now reflect an in check by intersecting with Record<K, T>.
The RWC test suite has a few new errors due to in being applied to unconstrained type parameters (a good change). There is also one suspicious error in RxJS where we now correctly narrow to never because the types indicate that the false branch will never happen. The code tests an XMLHttpRequest for the "response" property, which is declared as a non-optional property and therefore should always be present. Apparently there are corner cases with old IE versions where it isn't.
No changes in Definitely Typed tests.
The top 100 tests are catching new errors in react-select and react-bootstrap (a good change). There are also new errors in several tabby-* packages. They're due to fact that intersecting with Record<K, T> creates a type that is sufficiently different for an as type assertion to become an error. It's unfortunate, but acceptable I think.
Performance is unchanged.

One question I'm looking for feedback on is this:
function foo1(x: {}) {
    if ("a" in x) {
        x;  // Record<"a", unknown>
    }
}

The tightened operand validation rules requires the right hand operand to be of a type that is assignable to object. Unfortunately, {} is (unsoundly) assignable to object, even when the {} doesn't originate in a fresh object literal. A non-fresh {} can be any type except null or undefined. This includes primitive types, which, as right hand operands, cause the in operator to throw an exception. We have previously rejected fixing the {} assignable to object issue due to breaking change concerns, but we could conceivably error for a right hand {} type with the in operator.
The issue above is particularly unfortunate in --strictNullChecks mode because the the following doesn't error:
function foo(x: unknown) {
    if (x && "a" in x) {
        x;  // Record<"a", unknown>
    }
}

The truthy check narrows x from unknown to {} and we then permit the in check when it could actually be a primitive type that raises an exception. The check needs to be written x && typeof x === "object" && "a" in x to actually be safe.
I'm leaning towards closing this hole, though it may cause additional breaks.

@typescript-bot pack this

The check needs to be written x && typeof x === "object" && "a" in x to actually be safe.

I think it’s pretty valuable for TypeScript to be able to reason about and enforce this pattern—it comes up any time code needs to safely probe the shape of an unknown call argument, JSON response shape, etc., and it is easy to forget you need one of those conditions.

This is awesome!!!
I make some tests with the TS playground and seems number and symbol key doesn't work for me. Is there something wrong?
Reproduction here.

@typescript-bot test this
@typescript-bot user test this inline
@typescript-bot run dt
@typescript-bot test top100

@typescript-bot test this
@typescript-bot user test this inline
@typescript-bot run dt
@typescript-bot test top100

The outcome of disallowing {} as the type of the right operand is bit of a mixed bag. It catches the issue of applying in to an insufficiently narrowed unknown mentioned here, but it also causes a number of false positives in code such as this:
const obj = {};  // Type inferred as {}
// Code that somehow adds properties to obj
if ("foo" in obj) {  // Error even though obj is obviously not a primitive
    // ...
}

In a sense the more correct type to infer from an empty object literal is object, but that seems like too dramatic change for this corner case. I may instead experiment with tracking whether a {} type resulted from narrowing an unknown, and only error in those cases.

In general, when key is of some non-finite type (like string), the only effect we can meaningfully reflect following a key in obj check is that obj[key] should be a valid expression (of type unknown), provided key and obj are both known not to have been modified since the check.

I apologize if this is not the proper place for this discussion, but why the "of type unknown" part? If the values of obj are known to be of a certain type (e.g. number for Record<string, number>), shouldn't the type of obj[key] match the value type even if key is of a non-finite type? That's assuming TypeScript knows that key and obj haven't changed, and you don't do anything more complex than val = key[obj].

@ehoogeveen-medweb Right, I wasn't being clear that I was talking about the case where there are no matching properties or index signatures for key. Currently, in that situation, even in a block guarded by key in obj we error on obj[key], but obviously you've proven that for the current values of obj and key, a property (of an unknown type) exists.

In a sense the more correct type to infer from an empty object literal is object, but that seems like too dramatic change for this corner case.

Do you have a sense of what this might break? Between our discussion about Records and Tuples and all the recent changes around {}, the distinction between “can access some set of properties” and “is an object” has been feeling increasingly important. We’ve made some progress toward untangling those, but many have been limited to {}, leaving types like { toString(): string } a bit confused:
let x: { toString(): string } | object = 3; // ok
if (typeof x !== "object") {
  x; // never
}

This sort of thing is getting awkward to work around, as in #49865, which was not sound but seemed necessary for capturing the intent of real-world, very reasonable-looking code. It would be great if we can move toward a world where the object-ness of objects is actually inferred.

Do you have a sense of what this might break?

A more precise way to type object literals would be { ... } & object, where { ... } is what we currently infer. This would then reduce to just object for an empty object literal. The intersection with object would reflect that we know this is an object as opposed to some primitive type. What would such a change break? An awful lot of baselines and $ExpectType tests for starters, but beyond that hard to know without trying.

@typescript-bot test this
@typescript-bot user test this inline
@typescript-bot run dt
@typescript-bot test top100

With latest commits results of running tests are again as described here, plus we now properly handle the issue of an insufficiently narrowed unknown. I believe this PR is ready to merge.

We're going to see so many of the is not assignable to type 'object'. on generics errors in the wild.

Worst case we can put the stricter checks under a new --strictInOperator option. But I definitely would prefer to avoid that.

One thing that's worth noting with this new behaviour is that it does actively make some things looser and less safe.
For example - someone unfamiliar with Map or Set might do this instead of using .has (for example - someone coming from python might do it)
declare const map: Map<string, unknown>;
if ("woopsie" in map) {
  // typeof map = Map<string, unknown> & Record<"woopsie", unknown>;
}

Previously there would be no refinement of the type, so you'd at least have that signal that you're doing it wrong when you tried to access that property.
But now with the type change it is easier to write bad code accidentally.
Given it didn't actually error before to do the bad thing - it's not a huge problem, I just thought it was worth flagging in case it was something that was worth special casing or solving in some way.

Yeah, it's something that came up in the last design meeting (and specifically a discussion with @ahejlsberg) and one thought was to possibly

Only introduce properties that are readonly because at least then you can't assign to them.
Make a special-case (what?)

@bradzacher While I agree that your example is very likely a mistake, it obviously is possible that someone has a Map with some additional properties that they want to test for. So, technically it is a valid scenario. Again, agree that it's highly likely to be an error, but perhaps better covered by a linter?

@ahejlsberg yeah a lint rule makes sense that way users can opt-in easily. Filed https://github.com/typescript-eslint/typescript-eslint/issues/5677

Sorry, but what about #43284? :(

Does this also fix: https://github.com/microsoft/TypeScript/issues/43614 ?

@andreialecu no, it doesn't: nightly TS playground. I had no idea that you can write an invariant this way in TS 😱

For me the problem got fixed when updating to TypeScript 4.9.
I also made a video about this improvement: https://www.youtube.com/watch?v=oPkthSFxAHc 🎬

authors: Andarist DanielRosenwasser VdustR ahejlsberg andreialecu andrewbranch bennycode bradzacher ehoogeveen-medweb marekdedic polkovnikov-ph


text:
Bump glob-parent to 5.1.2

Bump glob-parent to 5.1.2

@sinedied could you weigh in pls? thanks!

Thanks for the update!

authors: jlooper matifali sinedied

repo: microsoft/Web-Dev-For-Beginners

license: MIT


text:
Propose word changes for adding the script to App.vue

The script mentioned is not currently in the App.vue file, therefore the

hi, the two curricula have diverged, so I don't want to merge this, thanks


text:
What happens if WinAppDriver is initialized for the app that is already opened?

I have launched my application manually but If I tried to relaunch the same application by initializing the windows driver I could see two different things happening

In My machine, windows driver recognizes the application that is already opened
But in my colleague's machine, it is launching another instance.

WindowsDriver windowsDriver;
string WindowsApplicationDriverUrl = windowsApplicationDriverUrl;
AppiumOptions appCapabilities = new AppiumOptions();
appCapabilities.AddAdditionalCapability("app", applicationPath);
appCapabilities.AddAdditionalCapability("appWorkingDir", applicationDirectory);
windowsDriver = new WindowsDriver(new Uri(WindowsApplicationDriverUrl), appCapabilities);
if(windowsDriver.Title.IsNullOrEmpty())
{
appCapabilities = new AppiumOptions();
appCapabilities.AddAdditionalCapability("app", applicationPath);
appCapabilities.AddAdditionalCapability("appWorkingDir", applicationDirectory);
windowsDriver = new WindowsDriver(new Uri(WindowsApplicationDriverUrl), appCapabilities);  //// This is where the two scenarios that I mentioned is happening
IWebElement ele = windowsDriver.FindElementByName(applicationTopLevelWindow);
string appTopLevelWindowHex = int.Parse(ele.GetAttribute("NativeWindowHandle")).ToString("X");
appCapabilities = new AppiumOptions();
appCapabilities.AddAdditionalCapability("appTopLevelWindow", appTopLevelWindowHex);
}
return windowsDriver;

Your application supports multiple instances, better check if the application is running before you initialize the driver.

Yes, my application is running before I initialize my driver. But the issue is, it behaves differently in two different machines.

Not an issue with win app driver, just implemented a logic to kill the application before you launch your application

repo: microsoft/WinAppDriver


text:
Release/1.1 stable

Cherry picking #2509 into 1.1-stable

/azp run

Must have cherry-picked the wrong commit.

repo: microsoft/WindowsAppSDK


text:
Update WindowsAppSDK-RunHelixTests-Job.yml

Replacing the Helix queues for 21h1 with corresponding new Windows 10 Helix queues, because 21h1 is becoming out of service, so we can stop running tests on it. The new Windows 10 Helix queues will be kept up to date, always pointing to the latest public Windows 10 release.
For status checks on the develop branch, please use TransportPackage-Foundation
(https://microsoft.visualstudio.com/ProjectReunion/_build?definitionId=57248)
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.

/azp run


text:
Allow generation and use of Organization API Tokens

Feature Request: we would love to generate, manage and use Organization API Tokens rather than our own user ones since we do a lot of AppCenter CLI work through our CI/CD.
Let us know how we can help :)

I don't know about organization tokens, do we have that in the portal?
Have you considered using "app tokens" instead of user tokens? Those can easily be shared within a team of collaborators.

@jp-andre I cannot find it if it exists - but I think what you recommended might work for now, however, we automatically create the apps based off env etc....so it's a race-condition. Unless we have an overarching token which can create, build, deploy any app within the organisation (same deal as a normal user account). Does that make sense?

It totally makes sense but I'm afraid there is no support for org tokens at this point in app center, so this is not a CLI issue.
You can browse and open a new issue in https://github.com/microsoft/appcenter instead, though we may not be able to address the request in the near future, see note.

Got it! Thanks. Shall I leave this one here open and linked to for the future, or reopen later?

If you don't mind, we would rather close it here. Thanks for your understanding and follow-up on the main repo!

authors: jp-andre mrowles

repo: microsoft/appcenter-cli


text:
Reference pages for 'tile util' APIs - set 2

Put in some reference pages for the 'arcade-tile-util' APIs. This the follow on for #1.
Feel free to add/suggest more descriptive info/annotations.
RE: https://github.com/microsoft/pxt-arcade/pull/4691 and #1

@riknoll - you'll have to do the merge.

repo: microsoft/arcade-tile-util


text:
Website, update privacy link

Why are these changes needed?

Update privacy link on autogen blog website
Related issue number

Checks

[ ] I've included any doc changes needed for https://microsoft.github.io/autogen/. See https://microsoft.github.io/autogen/docs/Contribute#documentation to build and test documentation locally.
[ ] I've added tests (if relevant) corresponding to the changes introduced in this PR.
[ ] I've made sure all auto checks have passed.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (2ee944d) 26.63% compared to head (dcf1e28) 26.44%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #994      +/-   ##
==========================================
- Coverage   26.63%   26.44%   -0.19%
==========================================
  Files          28       28
  Lines        3777     3777
  Branches      858      858
==========================================
- Hits         1006      999       -7
- Misses       2700     2706       +6
- Partials       71       72       +1

Flag
Coverage Δ

unittests
26.44% <ø> (-0.14%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

@sonichi , it looks like this got removed from merge queue.
Can we readd?

authors: codecov-commenter victordibia

repo: microsoft/autogen


text:
daprd sidecar keeps restaring

Please provide us with the following information:

This issue is a: (mark with an x)

[X] bug report -> please search issues before submitting
[ ] documentation issue or request
[ ] regression (a behavior that used to work and stopped in a new release)

Issue description
daprd sidecar is constantly restarting, seems like health probe is tested. "Ready = False".
Now my container is not starting and is in unworking state.
I cant influence the healthz or readiness probes, because there are no cli options to set these in aca.
Daprd is version 1.11.6
Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Log
Liveness probe failed: HTTP probe failed with statuscode: 500
Readiness probe failed: HTTP probe failed with statuscode: 500
Related?
https://github.com/microsoft/azure-container-apps/issues/683
https://github.com/microsoft/azure-container-apps/issues/561

@chielos24 Could you please post the logs from the "daprd" container? You can look at the log streaming, or use Azure Log Analytics.
Without logs, it's hard to be able to provide more details.
PS: In many cases, these issues are caused by components not configured correctly.

Thanks for confirming!

repo: microsoft/azure-container-apps


text:
Added ability to mount 'tasks' volume readonly on Windows

Added ability to mount 'tasks' volume readonly on Windows

Could you please attach pipeline with successful run also?
https://dev.azure.com/v-sedob/CopyFilesOverSSHDebug/_build/results?buildId=230&view=logs&j=12f1170f-54f2-53f3-20dd-22fc7dff55f9&t=9c939e41-62c2-5605-5e05-fc3554afc9f5&l=17

@sdobrodeev let's have another round of testing here

@sdobrodeev could it make sense to implement agent knob to turn it on/off as Mark suggested - to be able to set it up?

Hi @mjroghelia. Сould you please review my changes?

Hi @mjroghelia. Сould you please review my changes?

@sdobrodeev @anatolybolshakov I want to try this out locally. Could you send me the YAML for the pipeline you used in testing?

@sdobrodeev @anatolybolshakov I want to try this out locally. Could you send me the YAML for the pipeline you used in testing?

@sdobrodeev @anatolybolshakov I want to try this out locally. Could you send me the YAML for the pipeline you used in testing?

This pipeline was used for testing:
`stages:

stage: TestCaseAllWritable
condition: always()

jobs:

job: CaseAllWritable
container:
image: mcr.microsoft.com/windows/servercore:ltsc2019
mountReadOnly:
tasks: False
work: False
steps:

task: CopyFiles@2
displayName: 'Copy Files to'
inputs:
Contents: "."
TargetFolder: "C:\__w\__tasks"

task: CopyFiles@2
displayName: 'Copy Files to'
inputs:
Contents: "."
TargetFolder: "C:\__w\"

stage: TestCaseAllReadOnly
condition: always()
jobs:

job: CaseAllReadOnly
container:
image: mcr.microsoft.com/windows/servercore:ltsc2019
mountReadOnly:
tasks: True
work: True
steps:

task: CopyFiles@2
displayName: 'Copy Files to'
inputs:
Contents: "."
TargetFolder: "C:\__w\__tasks"

task: CopyFiles@2
displayName: 'Copy Files to'
inputs:
Contents: "."
TargetFolder: "C:\__w\"

stage: TestCaseTasksReadOnly
condition: always()
jobs:

job: CaseTasksReadOnly
container:
image: mcr.microsoft.com/windows/servercore:ltsc2019
mountReadOnly:
tasks: True
work: False
steps:

task: CopyFiles@2
displayName: 'Copy Files to'
inputs:
Contents: "."
TargetFolder: "C:\__w\__tasks"

task: CopyFiles@2
displayName: 'Copy Files to'
inputs:
Contents: "."
TargetFolder: "C:\__w\"

stage: TestCaseWorkReadOnly
condition: always()
jobs:

job: CaseWorkReadOnly
container:
image: mcr.microsoft.com/windows/servercore:ltsc2019
mountReadOnly:
tasks: False
work: True
steps:

task: CopyFiles@2
displayName: 'Copy Files to'
inputs:
Contents: "."
TargetFolder: "C:\__w\__tasks"

task: CopyFiles@2
displayName: 'Copy Files to'
inputs:
Contents: "."
TargetFolder: "C:\__w\"`

@sdobrodeev @anatolybolshakov I want to try this out locally. Could you send me the YAML for the pipeline you used in testing?

This pipeline was used for testing:
`stages:

stage: TestCaseAllWritable
condition: always()

jobs:

job: CaseAllWritable
container:
image: mcr.microsoft.com/windows/servercore:ltsc2019
mountReadOnly:
tasks: False
work: False
steps:

task: CopyFiles@2
displayName: 'Copy Files to'
inputs:
Contents: "."
TargetFolder: "C:\__w\__tasks"

task: CopyFiles@2
displayName: 'Copy Files to'
inputs:
Contents: "."
TargetFolder: "C:\__w\"

stage: TestCaseAllReadOnly
condition: always()
jobs:

job: CaseAllReadOnly
container:
image: mcr.microsoft.com/windows/servercore:ltsc2019
mountReadOnly:
tasks: True
work: True
steps:

task: CopyFiles@2
displayName: 'Copy Files to'
inputs:
Contents: "."
TargetFolder: "C:\__w\__tasks"

task: CopyFiles@2
displayName: 'Copy Files to'
inputs:
Contents: "."
TargetFolder: "C:\__w\"

stage: TestCaseTasksReadOnly
condition: always()
jobs:

job: CaseTasksReadOnly
container:
image: mcr.microsoft.com/windows/servercore:ltsc2019
mountReadOnly:
tasks: True
work: False
steps:

task: CopyFiles@2
displayName: 'Copy Files to'
inputs:
Contents: "."
TargetFolder: "C:\__w\__tasks"

task: CopyFiles@2
displayName: 'Copy Files to'
inputs:
Contents: "."
TargetFolder: "C:\__w\"

stage: TestCaseWorkReadOnly
condition: always()
jobs:

job: CaseWorkReadOnly
container:
image: mcr.microsoft.com/windows/servercore:ltsc2019
mountReadOnly:
tasks: False
work: True
steps:

task: CopyFiles@2
displayName: 'Copy Files to'
inputs:
Contents: "."
TargetFolder: "C:\__w\__tasks"

task: CopyFiles@2
displayName: 'Copy Files to'
inputs:
Contents: "."
TargetFolder: "C:\__w\"`

@sdobrodeev @anatolybolshakov I want to try this out locally. Could you send me the YAML for the pipeline you used in testing?

@mjroghelia This pipeline was used for testing:
stages:
- stage: TestCaseAllWritable
  condition: always()
  jobs:
  - job: TestCaseWeb
    container:
      image: mcr.microsoft.com/windows/servercore:ltsc2019
      mountReadOnly:
        tasks: True
        work: True
    steps:
    - task: CopyFiles@2
      displayName: 'Copy Files to'
      inputs:
        Contents: "*.*"
        TargetFolder: "C:\\__w\\__tasks"
    - task: CopyFiles@2
      displayName: 'Copy Files to'
      inputs:
        Contents: "*.*"
        TargetFolder: "C:\\__w\\"

- stage: TestCaseAllReadOnly
  condition: always()

  jobs:
  - job: TestCaseWeb
    container:
      image: mcr.microsoft.com/windows/servercore:ltsc2019
      mountReadOnly:
        tasks: False
        work: False
    steps:
    - task: CopyFiles@2
      displayName: 'Copy Files to'
      inputs:
        Contents: "*.*"
        TargetFolder: "C:\\__w\\__tasks"
    - task: CopyFiles@2
      displayName: 'Copy Files to'
      inputs:
        Contents: "*.*"
        TargetFolder: "C:\\__w\\"

- stage: TestCaseTasksReadOnly
  condition: always()
  jobs:
  - job: TestCaseWeb
    container:
      image: mcr.microsoft.com/windows/servercore:ltsc2019
      mountReadOnly:
        tasks: True
        work: False
    steps:
    - task: CopyFiles@2
      displayName: 'Copy Files to'
      inputs:
        Contents: "*.*"
        TargetFolder: "C:\\__w\\__tasks"
    - task: CopyFiles@2
      displayName: 'Copy Files to'
      inputs:
        Contents: "*.*"
        TargetFolder: "C:\\__w\\"

- stage: TestCaseWorkReadOnly
  condition: always()
  jobs:
  - job: TestCaseWeb
    container:
      image: mcr.microsoft.com/windows/servercore:ltsc2019
      mountReadOnly:
        tasks: false
        work: True
    steps:
    - task: CopyFiles@2
      displayName: 'Copy Files to'
      inputs:
        Contents: "*.*"
        TargetFolder: "C:\\__w\\__tasks"
    - task: CopyFiles@2
      displayName: 'Copy Files to'
      inputs:
        Contents: "*.*"
        TargetFolder: "C:\\__w\\"

Btw 'work is readonly' case is not actual - so let's just skip this one

@sdobrodeev @anatolybolshakov I want to try this out locally. Could you send me the YAML for the pipeline you used in testing?

@mjroghelia This pipeline was used for testing:
stages:
- stage: TestCaseAllWritable
  condition: always()
  jobs:
  - job: TestCaseWeb
    container:
      image: mcr.microsoft.com/windows/servercore:ltsc2019
      mountReadOnly:
        tasks: True
        work: True
    steps:
    - task: CopyFiles@2
      displayName: 'Copy Files to'
      inputs:
        Contents: "*.*"
        TargetFolder: "C:\\__w\\__tasks"
    - task: CopyFiles@2
      displayName: 'Copy Files to'
      inputs:
        Contents: "*.*"
        TargetFolder: "C:\\__w\\"

- stage: TestCaseAllReadOnly
  condition: always()

  jobs:
  - job: TestCaseWeb
    container:
      image: mcr.microsoft.com/windows/servercore:ltsc2019
      mountReadOnly:
        tasks: False
        work: False
    steps:
    - task: CopyFiles@2
      displayName: 'Copy Files to'
      inputs:
        Contents: "*.*"
        TargetFolder: "C:\\__w\\__tasks"
    - task: CopyFiles@2
      displayName: 'Copy Files to'
      inputs:
        Contents: "*.*"
        TargetFolder: "C:\\__w\\"

- stage: TestCaseTasksReadOnly
  condition: always()
  jobs:
  - job: TestCaseWeb
    container:
      image: mcr.microsoft.com/windows/servercore:ltsc2019
      mountReadOnly:
        tasks: True
        work: False
    steps:
    - task: CopyFiles@2
      displayName: 'Copy Files to'
      inputs:
        Contents: "*.*"
        TargetFolder: "C:\\__w\\__tasks"
    - task: CopyFiles@2
      displayName: 'Copy Files to'
      inputs:
        Contents: "*.*"
        TargetFolder: "C:\\__w\\"

- stage: TestCaseWorkReadOnly
  condition: always()
  jobs:
  - job: TestCaseWeb
    container:
      image: mcr.microsoft.com/windows/servercore:ltsc2019
      mountReadOnly:
        tasks: false
        work: True
    steps:
    - task: CopyFiles@2
      displayName: 'Copy Files to'
      inputs:
        Contents: "*.*"
        TargetFolder: "C:\\__w\\__tasks"
    - task: CopyFiles@2
      displayName: 'Copy Files to'
      inputs:
        Contents: "*.*"
        TargetFolder: "C:\\__w\\"

Btw 'work is readonly' case is not actual - so let's just skip this one

authors: anatolybolshakov mjroghelia sdobrodeev

repo: microsoft/azure-pipelines-agent


text:
AzureResourceGroupDeployment@2 doesn't support multi-line strings

Type: bug
Enter Task Name: AzureResourceGroupDeployment
Environment

Azure Pipelines
Agent Info:

Issue Description
It seems like the AzureResourceGroupDeployment task doesn't handle correctly multi-lines in my ARM template. There is a user-defined function in my template. While this version is deployed without any problem

the version when the value is split into multiple lines is failing:

According to the documentation this should work. And actually, the ARM template is deployed successfully when the PowerShell is used. But when I'm trying to deploy it with use of Azure Resource Group Deployment Task, it fails:

2021-01-22T11:50:15.6031626Z Creating deployment parameters.

2021-01-22T11:50:15.6205264Z The detected encoding for file 'D:\a\1\s\infra\configuration\DailyProcessing\azuredeploy.json' is 'utf-8'

2021-01-22T11:50:15.6318501Z ##[error]Check out the troubleshooting guide to see if your issue is addressed: https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/azure-resource-group-deployment?view=azure-devops#troubleshooting

2021-01-22T11:50:15.6340620Z (node:1588) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.

2021-01-22T11:50:15.6346063Z ##[error]Error: Ensure the Template file ( 'D:\a\1\s\infra\configuration\DailyProcessing\azuredeploy.json' ) is valid. Task failed while parsing with following error: Unexpected token in JSON at position 2127

2021-01-22T11:50:15.6449989Z ##[section]Finishing: DailyProcessing-ru (configuration)

FYI, here is the screenshot of my testing pipeline I'm using to deploy the ARM template as well:
[Include task name(s), screenshots and any other relevant details]

Error logs

2021-01-22T11:50:15.6318501Z ##[error]Check out the troubleshooting guide to see if your issue is addressed: https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/azure-resource-group-deployment?view=azure-devops#troubleshooting

2021-01-22T11:50:15.6340620Z (node:1588) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.

2021-01-22T11:50:15.6346063Z ##[error]Error: Ensure the Template file ( 'D:\a\1\s\infra\configuration\DailyProcessing\azuredeploy.json' ) is valid. Task failed while parsing with following error: Unexpected token in JSON at position 2127

I can confirm I have seen this as well. Ensured the ARM template had a schema set to the latest value in case that had an effect (https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#).
This would be very useful to have, more complex statement are difficult maintain when they are all on a single line.

I'm having a similar issue with the ARM template deployment@3 task. I originally thought it was an issue with Azure DevOps since I was running the ARM template successfully through Azure CLI.

Just commenting to say this is definitely still something we would find useful 👍

authors: PatrickMessierGoC hwride renenaplava

repo: microsoft/azure-pipelines-tasks


text:
IISWebAppManagementOnMachineGroup Remove username and password when they are not required

Is it possible to remove the username and password for Virtual Directory on a website.
I am using yaml to deploy a website which app pool already configured, noted that everytime I use ADO to deploy the applicationhost.config file has been updated as
 <site name="MyWebsite" id="12" serverAutoStart="true">
                <application path="/" applicationPool="DotNetCorePortal-Pre-Prod">
                    <virtualDirectory path="/" physicalPath="c:\MyWebsite" userName="" password="[enc:AesProvider:3AvwL+dsx7Zf2oaniKfGVEbN0ox+mYeQaKkUsW1p6Lo=:enc]" />

The website fails to start with this username and password, the error is "Failed to decrypt attribute 'password' because the keyset does not exist" . I don't know if there is issue with my server or not, but I don't want do any fixes even the issue is the server itselft as it's a production server,
I understand the IIS is trying to encrypt the password evenif it's empty, but I want to get rid off the username and password completely. As if I manually remove them, the website worked just fine. e.g
<site name="MyWebsite" id="12" serverAutoStart="true">
                <application path="/" applicationPool="DotNetCorePortal-Pre-Prod">
                    <virtualDirectory path="/" physicalPath="c:\MyWebsite" />

The ADO output as follwing
##[debug]Updating website properties. Running command : "C:\Windows\system32\inetsrv\appcmd.exe"  set site /site.name:"MyWebsite" -applicationDefaults.applicationPool:"AppPool" -[path='/'].[path='/'].physicalPath:"c:\MyWebsite" -[path='/'].[path='/'].userName: -[path='/'].[path='/'].password:
##[debug]Entering Invoke-VstsTool.
##[debug] FileName: 'C:\Windows\system32\inetsrv\appcmd.exe'
##[debug] Arguments: ' set site /site.name:"MyWebsite" -applicationDefaults.applicationPool:"AppPool" -[path='/'].[path='/'].physicalPath:"c:\MyWebsite" -[path='/'].[path='/'].userName: -[path='/'].[path='/'].password:'
##[debug] RequireExitCodeZero: 'True'
"C:\Windows\system32\inetsrv\appcmd.exe"  set site /site.name:"MyWebsite" -applicationDefaults.applicationPool:"AppPool" -[path='/'].[path='/'].physicalPath:"c:\MyWebsite" -[path='/'].[path='/'].userName: -[path='/'].[path='/'].password:

I have also encountered this issue and I don't know what's causing it.
In case anyone else runs into this problem, you can add this task as a deployment step (replace $(iisWebsiteName) with whatever you need it to be):
# This is required because for some reason the pipeline creates a password against the virtual directory for the website even
# though it is never configured in the build: https://github.com/microsoft/azure-pipelines-tasks/issues/15792
# Be very careful if you're modifying this script. Make a backup of applicationHost.config beforehand.
- task: PowerShell@2
  displayName: Fix applicationHost.config
  inputs:
    targetType: inline
    script: |
      $applicationHostPath = "$env:SystemRoot\System32\inetsrv\config\applicationHost.config"
      $siteName = "$(iisWebsiteName)"
      $virtualDirectoryNodePath = "//configuration/system.applicationHost/sites/site[@name='$siteName']/application/virtualDirectory"
      $xml = [xml](Get-Content $applicationHostPath)
      $virtualDirectoryNode = $xml.SelectSingleNode($virtualDirectoryNodePath)
      $virtualDirectoryNode.RemoveAttribute("userName")
      $virtualDirectoryNode.RemoveAttribute("password")
      $xml.save($applicationHostPath)

authors: GeorgieH Hotjava


text:
Azure Arc enabled API management on Cluster API

Deploy Azure Arc enabled API management on Cluster API in Azure.

Made the changes


text:
Add support for new database and restore DB directly from BAK

The Frustration of missing functionality is high!
Currently in ADS there is no way to create a new database via the UI. In my case this means a SQL Server database, on premise, installed on my machine. I found an extension that gives you a "New Database" option in the context menu for the Databases node in the server pane, but it woefully in adequate as all it does is ask for a name, there are no options to control initial size, growth options like you get in SSMS. Thus, I always end up switching back to using SSMS whenever I need to do this.
Similar to above sometimes I have a .bak file and I want to restore that to a new database directly without first having to create a new blank database. Again, there is no option to do this in the UI. The only way to restore a DB is to use the context menu on an existing database.
Solution I'd like
When you bring up the context menu on the database node there should be a new options:

"Restore database..." - When used, a dialog similar to the one when you are restoring an existing DB should be shown, except it should in addition prompt you for a new name for the DB.
"New database..." - When used, a dialog should be shown that prompts for name, size and growth configuration, see SSMS, except better UI layout.

Alternatives I've considered
I tried using extensions but they are poor and in my eyes this is MVP functionality that should already be there, I shouldn't need to use extensions for this.
Additional context
I know you don't like to hear this, you want separate tasks for every thing, but you need to look at SSMS and implement the many quality of life features that ADS is still missing, there are tasks for some of them - cause I wrote some as have others. Features like notebooks are all very well and good but when ADS is still missing basic functionality such as the above it causes a hard eye roll. I really want to get rid of SSMS altogether and use ADS full time, but it's still not possible. I end up having to have both open. SSMS is a very heavy weight extension for ADS and it would be useful to be able to uninstall it and not have it running at the same time as ADS.

@peterlukerow thanks for the feedback.  Regarding "Restore from a BAK", If you open the Manage dashboard for a Server there is a Restore Toolbar button that allows you to launch the Restore dialog without any existing DBs. (also, if you launch Restore from any DB you can set the restore target to a new DB name to create a new database).  Is the request there to add a "Restore" context menu to the server node in OE to make this a little more clear?
Regarding New Database, we haven't done this yet mostly due to how we're thinking about functionality in ADS vs. SSMS and other tools we ship.  Though as you explain, perhaps some of these basic admin functions should be in ADS as well.

@kburtram - thanks for that info. Hopefully you can see that the existing UX is not that great since it didn't make much sense to me to even look there.
Having restore in a context menu on the database node in the server pane is simply put far more intuitive to me. I mean, ADS has backup/restore context menu options when you right click an existing DB after all.
Hmmm.... I don't like the sound of your final comment of ADS vs. SSMS. I want to use ADS because it has dark mode out the box and because intellisense is much faster. But like I said there are lots of quality of life UX things that ADS doesn't do resizing columns, selecting more than 1 section of the printed output of a query without using the context menu copy all method is broken, drag/dropping column node of a table to get a full column list in query windows etc.. etc... these should not be consider things to be left behind in SSMS they should have been done months ago. Surely it would be easier for MS to have 1 tool that 2 to maintain. Or rather MS is leaving SSMS to fester, see the hack that is still required to get a broken dark mode enabled - years later.
The lack of create new database function built in is, in my eyes, a grave mistake and means ADS is not yet MVP. It is the most basic of things you need to do when working with a database server.

@kburtram my mistake, you are entirely correct with regards to the restore dialog accessed from the manage server dashboard. I got confused between source and target. I'm going to chalk that up to not focusing on one thing at a time.
It's good news that an engineer has been assigned to work through at least some of the UX problems. I apologise for some of the harshness in my replies, I'd been butting heads with the UI a lot recently and have reported several tickets about individual issues over time.
@alanrenmsft - if you could get create database functionality, drag/drop auto-generation of columns/tables and column resizing in tables of data stuff implemented/working along with other UI improvements, I and the many others would celebrate you like a deity!

+1
New Database and BackUp/Restore is nearing the only reason I open SSMS these days.
There is a new database extension but would be nice to have OOB.
Thanks for listening.

authors: joshbooker kburtram peterlukerow

repo: microsoft/azuredatastudio


text:
Ability to FIND IN RESULTS GRID to search ALL columns for a given value

Is your feature request related to a problem? Please describe.
After running a query and getting a resultset I'd like to be able to quickly search all columns of the results grid for a specified value.
Describe the solution or feature you'd like
Ability to hit CTRL + F or else right-click in the results grid and have the option to search all columns of the results grid (not the SQL script)
Describe alternatives you've considered

Export to CSV then open in Excel then CTRL+F.
Use the filtering dropdown in the column heading but it only searches the CURRENT column and not ALL columns.

Additional context

Same need here. Please include the result headers in the search as well.

authors: gregclerk tlunsfordCXP


text:
Unable to process the existing user settings and will overwrite the file with user settings from this session

Type: Bug
Extension : Database Administration Tool Extensions for Windows
Each time I click on Properties (Admin Tools) or Generate Scripts. I have an error Unable to process the existing user settings and will overwrite the file with user settings from this session that looks like it comes from SSMS. (full error below).
When I delete the file UserSettings.xml, I don't have the error anymore.
When I launch SSMS, connect to a database, the UserSettings.xml file comes back and I get the error again in Azure Data Studio.
===================================

Unable to process the existing user settings and will overwrite the file with user settings from this session. A backup of this file could be used to reattempt loading in those settings or for diagnostics by contacting Microsoft through https://aka.ms/sqlfeedback

Would you like the existing user settings file to be copied to C:\Users\adm-a.billon\AppData\Roaming\Microsoft\SQL Server Management Studio\19.0\UserSettings-2023-08-25_15-18Backup.xml?

===================================

Il existe une erreur dans le document XML (101, 8). (System.Xml)

------------------------------
Program Location:

   à System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events)
   à System.Xml.Serialization.XmlSerializer.Deserialize(Stream stream)
   à Microsoft.SqlServer.Management.UserSettings.Settings`1.InitializeCurrentUserSettingsInternal()

===================================

La référence d'objet n'est pas définie à une instance d'un objet. (Microsoft.SqlServer.Management.UserSettings)

------------------------------
Program Location:

   à Microsoft.SqlServer.Management.UserSettings.ScriptingOptions.set_TargetVersion(String value)
   à Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderSqlStudio.Read13_ScriptingOptions(Boolean isNullable, Boolean checkType)
   à Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderSqlStudio.Read43_SSMS(Boolean isNullable, Boolean checkType)
   à Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderSqlStudio.Read44_SqlStudio(Boolean isNullable, Boolean checkType)
   à Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderSqlStudio.Read45_SqlStudio()

Extension version: 0.1.3
Azure Data Studio version: azuredatastudio 1.45.1 (88c21b1725a3e79440027bdb7b5a55fb036be0e2, 2023-08-03T00:42:37.945Z)
OS version: Windows_NT x64 10.0.22621
Restricted Mode: No
Preview Features: Enabled
Modes:
SSMS Version
SQL Server Management Studio						19.1.56.0
SQL Server Management Objects (SMO)						16.200.48044.0+eeb184ee48a91ebc6a27a5d192c0d67bdfaae8b6
Microsoft T-SQL Parser						17.0.8.0+3c5555b8bd579d12add8f155f1dbc871e3e734c4
Outils clients Microsoft Analysis Services						16.0.20010.0
Microsoft Data Access Components (MDAC)						10.0.22621.1992
Microsoft MSXML						3.0 6.0
Microsoft .NET Framework						4.0.30319.42000
Système d'exploitation						10.0.22621

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz (8 x 1800)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: enabled

Load (avg)
undefined

Memory (System)
15.85GB (5.61GB free)

Process Argv

Screen Reader
no

VM
0%

same issue with ssms 20-20.2 i think its ssms specific not azure


text:
add title and tab-index for X button

This PR fixes #11528

Pull Request Test Coverage Report for Build 270073944

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 38.084%

Totals

Change from base Build 269776218:
0.0%

Covered Lines:
19144

Relevant Lines:
45868

💛  - Coveralls

authors: alanrenmsft coveralls


text:
Aasim/fix/sqldbtypos

This PR fixes #12955
When option is disabled

When option is enabled

Help text

Pull Request Test Coverage Report for Build 335122179

17 of 46 (36.96%)  changed or added relevant lines in 8 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.008%) to 39.573%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

extensions/resource-deployment/src/ui/deployAzureSQLDBWizard/pages/summaryPage.ts
0
2
0.0%

extensions/resource-deployment/src/ui/deployAzureSQLDBWizard/deployAzureSQLDBWizardModel.ts
0
5
0.0%

extensions/resource-deployment/src/ui/deployAzureSQLDBWizard/pages/databaseSettingsPage.ts
1
23
4.35%

Files with Coverage Reduction
New Missed Lines
%

extensions/resource-deployment/src/ui/deployAzureSQLDBWizard/deployAzureSQLDBWizardModel.ts
1
16.67%

Totals

Change from base Build 335036709:
-0.008%

Covered Lines:
20638

Relevant Lines:
47891

💛  - Coveralls


text:
Pick up electron update

Update to latest electron

Pull Request Test Coverage Report for Build 552380191

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 41.152%

Totals

Change from base Build 499673990:
0.0%

Covered Lines:
21844

Relevant Lines:
48631

💛  - Coveralls

authors: coveralls kburtram


text:
auto focus message area

For: #22742

Pull Request Test Coverage Report for Build 4704577785

0 of 1 (0.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.0004%) to 41.649%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/sql/workbench/browser/modal/modal.ts
0
1
0.0%

Totals

Change from base Build 4704487804:
-0.0004%

Covered Lines:
30344

Relevant Lines:
67449

💛  - Coveralls


text:
fix DefaultValueResponce can't access DialogContext.State

closes: #4409
I have an E2E test for this fix: Here is the dialog file
{
  "$schema": "../../testbot.schema",
  "$kind": "Microsoft.AdaptiveDialog",
  "triggers": [
    {
      "$kind": "Microsoft.OnBeginDialog",
      "actions": [
        {
          "$kind": "Microsoft.SendActivity",
          "$designer": {
            "id": "859266",
            "name": "Send a response"
          },
          "activity": "Welcome User!"
        },
        {
          "$kind": "Microsoft.NumberInput",
          "defaultLocale": "en-us",
          "disabled": false,
          "maxTurnCount": 2,
          "alwaysPrompt": true,
          "allowInterruptions": false,
          "prompt": "Give me your favorite number (1-10)",
          "unrecognizedPrompt": "Sorry, ${turn.activity.text} did not include a valid number.",
          "invalidPrompt": "Sorry, ${this.value} does not work. Can you give me a different number that is between 1-10?",
          "defaultValueResponse": "Sorry, we have tried for ${class.MaxTurnCount} number of times and I'm still not getting it. For now, I'm setting ${class.property} to ${class.DefaultValue}",
          "property": "user.favoriteNumber",
          "outputFormat": "=string(this.value)",
          "validations": [
            "=int(this.value) >=1",
            "=int(this.value) <= 10"

          ],
          "defaultValue": 9
        },
        {
          "$kind": "Microsoft.SendActivity",
          "activity": "${user.favoriteNumber}"
        }
      ]
    }
  ]
}

The result is:

@cosmicshuai can you just check in the E2E test somewhere?

@boydc2014
I did the E2E test.
I created a bot in Composer, and run it in the Testbot.json.
I can upload the project somewhere, and append in the description.

@boydc2014
I did the E2E test.
I created a bot in Composer, and run it in the Testbot.json.
I can upload the project somewhere, and append in the description.

I mean in the test projects, we have UT which can test a full declarative dialog, right? can we check in a new test case to ensure this behavior is right?

Please also add cancellationToken to the EndDialogAsync call in InputDialog's ContinueDialogAsync method:
return await dc.EndDialogAsync().ConfigureAwait(false);

Thanks!

@EricDahlvang
cancellationToken in EndDialogAsync has been added

authors: EricDahlvang boydc2014 cosmicshuai

repo: microsoft/botbuilder-dotnet


text:
[PORT] [QnA Maker] header change for adding "Ocp-Apim-Subscription-Key"

Port this change from botbuilder-dotnet/master branch:
https://github.com/microsoft/botbuilder-dotnet/pull/3690

For supporting QnAMaker V2 integration
Changed projects

Microsoft.Bot.Builder.AI.QnA

Closed via #2001

authors: stevengum tomlm

repo: microsoft/botbuilder-js


text:
fix: [#4204] Fix remaining eslint warnings - Rest of botbuilder-dialogs libraries - botbuilder declarative

Addresses #4204
#minor
Description
This PR fixes the ESLint and JSDoc issues in the botbuilder-dialogs-declarative library.
Specific Changes

Applied auto-fixes with yarn lint --fix

Fix spacing
Fix indentation
Add blank line in between comments
Add trailing commas
Missing parameters in descriptions

Applied manual fixes for:

Missing documentation
Unnecessary escape characters
Disabling detect-non-literal-fs-filename rule to allow dynamic path for files

Testing
Library eslint status

Test:compat

Pull Request Test Coverage Report for Build 2314798721

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage remained the same at 84.483%

Files with Coverage Reduction
New Missed Lines
%

libraries/botbuilder-lg/src/templateExtensions.ts
1
84.48%

Totals

Change from base Build 2245574340:
0.0%

Covered Lines:
19902

Relevant Lines:
22310

💛  - Coveralls

authors: coveralls sw-joelmut


text:
Latest language files for es-US

File-set: account.json, mutation.json, tags.json, specialists.json, services.json, requests.json, reporting.json, passwordReset.json, login.json, footer.json, common.json and clients.json

I will allow you guys @darthtrevino @devan-huapaya @batch08 to merge in this pr at the best time for the project rather than I do it now which may destabilize