Microsoft

Insert key doesn't switch to overtype/overwrite mode

Insert key should switch between insert and overtype modes but it does not. Version 0.10.3 Commit 783ecf841a2b21edca6d86853670cae89b4c244f Date 2015-11-26T14:10:14.207Z Shell 0.34.1 Renderer 45.0.2454.85 Node 4.1.1 Ubuntu 14.04

Allow for floating windows

Hi, I suggest floating windows option for: - Terminal - Debug console - Problems - Output Eventually: - tabs - Explorer / search / debug / git / extensions This way we could take advantage of large screen space and / or multi monitors. Having to constantly switch between the various windows is not optimum working flow.

Git: Support git with private key password

- VSCode Version: 1.6.0 - Commit e52fb0bc87e6f5c8f144e172639891d8d8c9aa55 - Date 2016-10-10T18:37:40.189Z - Shell 1.3.7 - Renderer 52.0.2743.82 - Node 6.5.0 - OS Version: Windows 7 Pro Steps to Reproduce: 1. Create a public-private key pair with password protection 2. add them to your github account 3. setup git to use the private key file 4. try to push something with git Result: [code block]

Vscode, have you collaborated with China?

请大家不要在这里发无关的issue了，这是对开发者的骚扰。我们在这里的issue已经给开发者造成了诸多麻烦，请大家不要再去提交issue了。我也很理解大家的心情，当初看到这玩意儿的时候我也是很震惊很不爽的，毕竟这玩意就加个vip套皮然后就宣称国产自研，你说这些不如信我是秦始皇。确实国产cec-ide很垃圾就是个套壳，丢国人的脸。但我们在这里乱提交issue不也是很丢脸的事情吗？这里是GitHub，不是QQ群或者贴吧垃圾场。 Please everyone do not post irrelevant issues here, this is harassment of developers. Our issue here has caused a lot of trouble for developers, please do not submit issues here. I also understand everyone's mood, when I first saw this thing, I was very shocked and angry, too. This thing added a vip and then claimed that the domestic self-research, how ridiculous and absurd this is. It is true that cec-ide is a piece of shit. But isn't it impolite for us to bother developers here? This is GitHub, not a dump. *** A Chinese IDE (which is called "CEC-IDE") claimed that they developed a new IDE by themselves: I downloaded this software and installed it, and it looked so similar to vscode: I read the CEC-IDE official document, it seems to need paying to use. I have carefully read their relevant documents and reviewed their software, but I did not find any statement similar to "open source following the MIT license".

New VS Code icon is ugly!

Can we return previous app icon or draw a new one? It really looks bad. https://code.visualstudio.com/images/1_17_windows-stable-orange.png

Proper tabs for open files

I _really_ miss proper tabs for open files (like VS proper), and the ability to rip a tab out into its own window.

[BUG] Npm opens many connections when installing

Is there an existing issue for this? - [X] I have searched the existing issues This issue exists in the latest npm version - [X] I am using the latest npm Current Behavior My project needs around 2000 packages. When running "npm install" it starts out by opening 2000 connections and then when all the connections are open it downloads 1 package on each connection. Is this intended?, because it causes a quite high load on our package proxy. Is there a way to limit the number of connections? With npm 9.9 it only uses 18/20 connections. Expected Behavior "npm install" only opens a few connetions to the package server. Steps To Reproduce 1. Clear cache 2. npm install or npm ci Environment - npm: 10.2.5 - Node.js: 18.19.0 - OS Name: Windows 11 - System Model Name: - npm config: [code block]

[BUG] npm update does not save new versions in package.json

Current Behavior: When running `npm update`, packages are updated normally, package-lock.json is updated, but package.json is not. (`npm install [package]@[version]` does update package.json as expected.) Expected Behavior: The package.json file should be updated with the newly installed versions, as specified in the npm-update docs. Steps To Reproduce: - `npm update` - Check package.json Environment: OS: Mac OS Big Sur Node: 14.15.5 NPM: 7.5.4

Tabs for integrated terminal

Status update from @Tyriar: - We started exploring this in March https://github.com/microsoft/vscode/issues/10546#issuecomment-800286034 - April plan: https://github.com/microsoft/vscode/issues/120241 - Tabs have landed in Insiders work in progress & call for feedback https://github.com/microsoft/vscode/issues/10546#issuecomment-823291688 - Moved to backlog to cover terminals in editor area https://github.com/microsoft/vscode/issues/10546#issuecomment-826900427 - Assigned to June for "terminal editors" https://github.com/microsoft/vscode/issues/10546#issuecomment-852971002 - Terminal editors plan filled in (https://github.com/microsoft/vscode/issues/125514), request for feedback https://github.com/microsoft/vscode/issues/10546#issuecomment-860644971 --- Feature request. Default terminal But could be more usable...

[FEATURE] Do not remove node_modules on npm ci

What / Why I would really like to see a flag like `npm ci --keep` to do an incremental update on our buildserver as this would speed up our deployments a lot. Like suggested before on github and on the community. The last update was on the 7th of October that this was being reviewed by the cli team. Could someone post an update on this? :-)

Support [skip ci] out of box with github actions

Pretty much every other ci/cd solution will skip running a workflow/pipeline if `[skip_ci]` is in the commit text. Currently the hack for this is to add an `if` statement to jobs with something like `"! contains(toJSON(github.event.commits.*.message), '[skip-ci]')"`. However, this still runs the workflow, just not any jobs with the condition. Please provide an out of box way for this to happen. One solution would be something like paths-ignore: [code block] @eseay

[BUG] ExperimentalWarning: Support for loading ES Module in require() is an experimental feature and might change at any time

Is there an existing issue for this? - [X] I have searched the existing issues This issue exists in the latest npm version - [X] I am using the latest npm Current Behavior When installing any package with Node.js v23.0.0 and npm v10.9.0, I get the following warning [code block] Expected Behavior _No response_ Steps To Reproduce _No response_ Environment - npm: 10.9.0 - Node.js: 23.0.0 - OS Name: Windows 10 22H2 - npm config: default [code block]

[BUG] npm update --global fails: npm ERR! global requires an add or rm option

Current Behavior: [code block] Expected Behavior: Before v7.0.0, running `npm update --global` would update all the packages installed globally which are outdated. Steps To Reproduce: Install an outdated global package, and try to update all the packages. Environment: - OS: Ubuntu 20.04.1 - Node: 12.19.0 - npm: 7.0.0

[BUG] ^7.20.3 no longer resolves local package first on install (workspaces)

Is there an existing issue for this? - [X] I have searched the existing issues Current Behavior In a workspaces based environment, for example: [code block] Running `npm install b --workspace a` will no longer install the locally linked package correctly. Instead, it'll use the version hosted on `npm`, or throw a 404 if you use a custom (unique) package name. Expected Behavior In <7.20.x, NPM would resolve the local package, and correctly alter package.json and package-lock.json. Steps To Reproduce With `node v16.6.1` and `npm 7.20.3` installed: 1) Make a new directory [code block] 2) Add a package.json [code block] 3) Setup 2 workspace packages [code block] (I used `@rijk/a` and `@rijk/b` as names, to avoid confusion with the existing packages `a` and `b`.) 5) Run `npm install` in the root, to give it a chance to npm link all the packages (not sure if needed) [code block] 6) Try installing `@rijk/b` as a dependency of `@rijk/a` [code block] 5) See error... [code block] --- If you install `7.20.2` or below (`npm i -g npm@7.20.2`), the above flow still works as expected. Environment - OS: macOS 11.4, also seen in GitHub Actions - Node: v16.6.1 - npm: 7.20.3 and up

[BUG] npm install will randomly hang forever and cannot be closed when this occurs

Is there an existing issue for this? - [X] I have searched the existing issues This issue exists in the latest npm version - [X] I am using the latest npm Current Behavior When running `npm install` it will sometimes hang at a random point. When it does this, it is stuck forever. CTRL+C will do nothing the first time that combination is pressed when this has occurred. Pressing that key combination the second time will make the current line (the one showing the little progress bar) disappear but that's it. No further responses to that key combination are observed. The CMD (or Powershell) window cannot be closed regardless. The process cannot be killed by Task Manager either (Access Denied, although I'm an Administrator user so I'd assume the real reason is something non-permissions related). The only way I have found to close it is to reboot the machine. My suspicion is it's some sort of deadlock, but this is a guess and I have no idea how to further investigate this. I've tried using Process Explorer to check for handles to files in the project directory from other processes but there are none. There are handles held by the Node process npm is using, and one for the CMD window hosting it, but that's it. Even running with `log-level silly` yields no useful information. When it freezes there are no warnings or errors, it just sits on the line it was on. This is some log output from one of the times when it got stuck (I should again emphasise that the point whe

Suggestion: option to include undefined in index signatures

Update: fixed by `--noUncheckedIndexedAccess` in TypeScript 4.1 --- Update: for my latest proposal see comment https://github.com/Microsoft/TypeScript/issues/13778#issuecomment-406316164 With `strictNullChecks` enabled, TypeScript does not include `undefined` in index signatures (e.g. on an object or array). This is a well known caveat and discussed in several issues, namely https://github.com/Microsoft/TypeScript/issues/9235, https://github.com/Microsoft/TypeScript/issues/13161, https://github.com/Microsoft/TypeScript/issues/12287, and https://github.com/Microsoft/TypeScript/pull/7140#issuecomment-192606629. Example: [code block] However, it appears from reading the above issues that many TypeScript users wish this wasn't the case. Granted, if index signatures did include `undefined`, code will likely require much more guarding, but—for some—this is an acceptable trade off for increased type safety. Example of index signatures including `undefined`: [code block] I would like to know whether this behaviour could be considered as an extra compiler option on top of `strictNullChecks`. This way, we are able to satisfy all groups of users: those who want strict null checks with or without undefined in their index signatures.

[BUG] npm update not updating package.json

npm update does not update and write to package.json node v12.14.1 npm v6.13.4 windows 10 pro 64-bit 1903 build 18362.592 Delete node_modules directory and package-lock.json, open cmd.exe and run the following: [code block] I'm expecting the contents of package.json to be updated. Here is my package.json: [code block]

add conditional execution of action steps

Describe the enhancement Add possibility to use `if:` option for action steps of composite actions. Code Snippet [code block]`

Configuration tries to use the registration endpoint even when passed `--token <token>`

Describe the bug When running the configuration of the runner unattended, some means of authenticating is required. The documentation at https://docs.github.com/en/rest/actions/self-hosted-runners#create-a-registration-token-for-an-organization claims that a token from that endpoint can be used with the `--token <token>` option. Instead, the runner attempts to obtain a new one with a PAT that may or may not be passed to it (See ConfigurationManager.cs#L111) In the case that it isn't, the configuration fails with a 404. To Reproduce Steps to reproduce the behavior: 1. Obtain a registration token from `https://api.github.com/orgs/ORG/actions/runners/registration-token`, where `ORG` is a valid organization. Call this registration token `TOKEN`. 2. Run `./config --unattended --url https://github.com/ORG --token TOKEN` 3. An error is printed out and the runner exits Expected behavior What is described to be possible in https://docs.github.com/en/rest/actions/self-hosted-runners#create-a-registration-token-for-an-organization Runner Version and Platform Version 2.291.1, Commit 496ec0df97891bd8e50f4431d01874ac3ab75a93 OS of the machine running the runner? OSX/Windows/Linux/... Linux, Ubuntu 20.04.4 LTS What's not working? [code block] Job Log Output N/A Runner and Worker's Diagnostic Logs N/A

Add ability to re-run single jobs

Please add the ability to re-run single jobs of a workflow. This is such a basic feature. Please keep the environment in mind while prioritizing features. 🙏

Support Harmony Next PC

[BUG] Platform-specific optional dependencies not being included in `package-lock.json` when reinstalling with `node_modules` present

Is there an existing issue for this? - [X] I have searched the existing issues This issue exists in the latest npm version - [X] I am using the latest npm Current Behavior [code block] I'm working on a team that utilizes a mix of x64-based and m1-based macs, and has CI build processes that uses musl. We're seeing that `npm` is skipping platform-specific optional dependencies for packages such as `@swc/core` as a result of the `package-lock.json` file being generated without all of them included. In our case, this then causes linting to throw an exception, because one of our eslint plugins depends on @swc, which depends on having the platform specific @swc package also installed. There seems to be at least two stages of cause to this. Firstly, when installing `@swc/core` from a clean slate working directory `npm` generates a `package-lock.json` with all of the optional dependencies for `@swc/core` listed: [code block] And it only installs the platform specific package: [code block] If I then remove my `package-lock.json`, leave my `node_modules` directory as-is, and then reinstall, I get: [code block] That is, it then generates a package-lock.json with only the platform-specific dependency that was installed on this machine, and not with the other optional dependencies that should also be listed. If you delete both `node_modules` AND `package-lock.json`, and then re-run `npm install`, it generates the correct lockfile with all of those optional dependencies list

Suggestion: `throws` clause and typed catch clause

The typescript type system is helpful in most cases, but it can’t be utilized when handling exceptions. For example: [code block] The problem here is two fold (without looking through the code): 1. When using this function there’s no way to know that it might throw an error 2. It’s not clear what the type(s) of the error is going to be In many scenarios these aren't really a problem, but knowing whether a function/method might throw an exception can be very useful in different scenarios, especially when using different libraries. By introducing (optional) checked exception the type system can be utilized for exception handling. I know that checked exceptions isn't agreed upon (for example Anders Hejlsberg), but by making it optional (and maybe inferred? more later) then it just adds the opportunity to add more information about the code which can help developers, tools and documentation. It will also allow a better usage of meaningful custom errors for large big projects. As all javascript runtime errors are of type Error (or extending types such as `TypeError`) the actual type for a function will always be `type | Error`. The grammar is straightforward, a function definition can end with a throws clause followed by a type: [code block] When catching the exceptions the syntax is the same with the ability to declare the type(s) of the error: `catch(e: string | Error) { ... }` Examples: [code block] Here it’s clear that the function can throw an error and that the e

Support final classes (non-subclassable)

I was thinking it could be useful to have a way to specify that a class should not be subclassed, so that the compiler would warn the user on compilation if it sees another class extending the original one. On Java a class marked with final cannot be extended, so with the same keyword on TypeScript it would look like this: [code block]

Conditional operator or function for expression syntax

Describe the enhancement I'd like some kind of conditional operation added to expression syntax. This can be an actual ternary operator (`?` `:`) or a built-in function (e.g., `if(<condition>, <true-value>, <false-value>)`). Additional information There is a workaround: using shell scripts to evaluate the condition, setting step outputs, and having other steps reference those outputs. But it would be much cleaner to have some kind of ternary / if/then/else / conditional branching built in to the expression syntax.

Concerns with TypeScript 4.5's Node 12+ ESM Support

For TypeScript 4.5, we've added a new module mode called `node12` to better-support running ECMAScript modules in Node.js. Conceptually, the feature is simple - for whatever Node.js does, either match it or overlay something TypeScript-specific that mirrors thes same functionality. This is what TypeScript did for our initial Node.js support (i.e. `--moduleResolution node` and `--module commonjs`); however, the feature is much more expansive, and over the past few weeks, a few of us have grown a bit concerned about the complexity. I recently put together a list of user scenarios and possibly useful scripts for a few people on the team to run through, and we found a few sources of concerns. Bugs UX Ecosystem User Guidance Bugs Most complex software ships with a few bugs. Obviously, we want to avoid them, but the more complex a feature is, the harder it is to cover all the use-cases. As we get closer to our RC date, do we feel confident that what we're shipping has as few blocking bugs as possible? I would like to say we're close, but the truth is I have no idea. It feels like we'll have to keep trying the features for a bit until we don't run into anything - but we have less than 3 weeks before the RC ships. Here's a few surprising bugs that need to get fixed before I would feel comfortable shipping `node12` in stable. Code changes breaking module resolution https://github.com/microsoft/TypeScript/issues/46373 https://github.com/microsoft/TypeScript/issues

Job-level "if" condition not evaluated correctly if job in "needs" property is skipped

Describe the bug If a job `needs` a prior job which has been skipped, the `if` condition for the dependent job may behave unexpectedly under some conditions. (unsure if condition is evaluated incorrectly or if it's not evaluated at all) To Reproduce Steps to reproduce the behavior: Given a workflow such as this (where job_b needs to complete or be skipped before subsequent jobs run, but subsequent jobs don't depend upon any outputs from job_b) [code block] Examining the output of this workflow, job_a will always run, job_b will always be skipped, job_c will always be skipped, and job_d will run. The only difference between job_c and job_d is the addition of `always() &&` to the `if` condition. Expected behavior If a job-level conditional evaluates to `true`, the job should run after all `needs`'d jobs have completed or been skipped. _Both_ job_c and job_d should run. The `always() &&` should not be required for job_c, since it doesn't change the ultimate true/false result of the conditional. OR documentation should be updated to indicate this is expected behavior. The current docks simply says of job `needs` (emphasis added): > Identifies any jobs that must complete successfully before this job will run. It can be a string or array of strings. If a job fails, all jobs that need it are skipped unless the jobs use a conditional statement that causes the job to continue. This is relatively ambiguous, but the plain interpretation is that a conditional statement that evaluates

Suggestion: allow get/set accessors to be of different types

It would be great if there was a way to relax the current constraint of requiring get/set accessors to have the same type. this would be helpful in a situation like this: [code block] Currently, this does not seems to be possible, and I have to resort to something like this: [code block] This is far from ideal, and the code would be much cleaner if different types would be allowed. Thanks!

Add support for cross-repo runners

Describe the enhancement Having an agent _per_ repo is very tedious and frustrating. It would be nice to have agents that can work across repositories to prevent potentially having hundreds of agents to maintain (with rotating tokens) across hundreds of repos Code Snippet n/a Additional information n/a

Disable runner auto update

Describe the bug We are running the runner in docker containers and it is forcing us to update the runner and shuts it down. Is there any way we can disable this? https://github.com/ydataai/docker-github-runner -> project with the Dockerfile to build runner in containers To Reproduce 1. Go to the folder where you have github-runner 2. execute ./run.sh 3. Run a job Expected behavior I want to run the runner without it forcing me to update and shutting down my docker Runner Version and Platform Version of your runner? v2.169.1 OS of the machine running the runner? Linux Job Log Output [code block] Runner and Worker's Diagnostic Logs Doesn't seem relevant.

Next Steps for Fully Functioning Composite Actions

NOTE: For those who are not aware, I'm a college student who interned at GitHub for Summer 2020. Thank you all for all the thoughtful comments and feedback on this thread but since I'm not working at GitHub currently, I will not be responding to any new comments below in this thread. ================================================ Hi there 👋 We just released a new feature called composite run steps actions(https://docs.github.com/en/actions/creating-actions/about-actions#composite-run-steps-actions). This issue thread will serve as a point of reference for people who are curious about the next steps after this feature and what we plan to work on next. There are probably quite a few questions about when we are going to support in the future like "when are you going to support 'uses' steps in a composite action"? In this Issue thread, I'll talk about the technical problems that we are planning to solve to accomplish this. Throughout the next week, I'll update it with any additional updates. tl;dr in this issue, I'll go over what we currently support for composite run steps and how we plan on developing fully functioning composite actions. Composite run steps background What is a composite run steps action? Many of you have been asking us to build a feature that enables them to nest actions within actions (ex: https://github.com/actions/runner/issues/438). An important first step for supporting nesting within action is to first start supporting the execution of multi

Suggestion: Range as Number type

When defining a type one can specify multiple numbers separated by `|`. [code block] Allow to specify number types as ranges, instead of listing each number: [code block] Maybe use `..` for integers and `...` for floats. [code block]

Environment Secrets are not available on Reusable Workflow / Workflow Templates

Describe the bug obs: this feature works as designed, but I believe it could be improved. Problem: Passing an environment containing secrets to a reusable workflow is not enough to have the environment secrets avaiable. Example: In a repository, there is an environment called "myenv", which contains a single secret called "MY_SECRET". In this repository, there is also a workflow calling a reusable workflow. This is the reusable workflow [code block]` And this is the workflow [code block]` When running this workflow, `MY_SECRET` isn't available. I see something like this in the logs: [code block]` instead of this [code block]` In order to make `MY_SECRET` available in the reusable workflow, I must explicitly write it in the workflow caller, like so: [code block]` Why can't the reusable workflow load all of the environment secrets automatically using just the environment's name? Is there a reason for not doing it? In this repo you can find all of my experiments: https://github.com/AllanOricil/workflow-template-bug Expected behavior "Deployment Environment" secrets should be available in reusable workflows What's not working? "Deployment Environment" secrets are not available in reusable workflows Job Log Output [code block]`

Suggestion: Regex-validated string type

There are cases, where a property can not just be any string (or a set of strings), but needs to match a pattern. [code block] It's common practice in JavaScript to store color values in css notation, such as in the css style reflection of DOM nodes or various 3rd party libraries. What do you think?

Duplicate type declarations with npm link

Using TypeScript 1.7.3. Suppose I have the below npm packages. The declaration files are generated by TypeScript compiler, and referred to from the other packages by means of the way described here. package-a ts src: [code block] ts declaration: [code block] package-b (depends on package-a): ts src: [code block] ts declaration: [code block] package-c (depends on package-a and package-b): ts src: [code block] The last line causes an error during compilation: [code block] When I remove the line `private foo;` from the declaration of package-a, TypeScript does not emit any error. However this workaround is a bit painful. I understand that exposing private properties to declaration is by design (https://github.com/Microsoft/TypeScript/issues/1532). I think TypeScript should ignore private properties when compiling variable assignment. Or is there any better workaround for this?

Support "medium-sized" projects

Listening to @nycdotnet has me fired up to tackle this one. Thanks, Steve. (btw, you can check out his good interview here: http://www.dotnetrocks.com/default.aspx?showNum=1149) The proposal here was first started in times prehistoric (even before #11), when dinosaurs walked the scorched earth. While nothing in this proposal is novel, per se, I believe it's high time we tackled the issue. Steve's own proposal is #3394. The Problem Currently, in TypeScript, it's rather easy to start and get going, and we're making it easier with each day (with the help of things like #2338 and the work on System.js). This is wonderful. But there is a bit of a hurdle as project size grows. We currently have a mental model that goes something like this: - Small-sized projects: use tsconfig.json, keep most of your source in the current directory - Large-sized projects: use custom builds, put source where you need it For small-sized projects, tsconfig.json gives you an easy-to-setup way of getting going with any of the editors in a cross platform way. For large-scale projects, you will likely end up switching to build systems because of the varied requirements of large-scale projects, and the end result will be something that works for your scenarios but is difficult to tool because it's far too difficult to tool the variety of build systems and options. Steve, in his interview, points out that this isn't quite the right model of the world, and I tend to agree with him. Instead, ther

npm ERR! Unexpected token '.' with with nvm-windows <= 1.1.7

Is there an existing issue for this? - [X] I have searched the existing issues This issue exists in the latest npm version - [X] I am using the latest npm Current Behavior I have updated to the latest npm v8.3.1 and it is showing me an error while using the command "npm outdated -g --depth=0". See the image; https://imgur.com/a/5fMZlye. It was fine on v8.3.0. What is the solution? Expected Behavior It should return the outdated packages after a successful run. But it is giving error. Steps To Reproduce 1. In this environment... 2. With this config... 3. Run '...' 4. See error... I am using Windows 10 (Enterprise - Latest Version). I have the latest node and npm installed at the moment. Environment - npm: - Node.js: - OS Name: - System Model Name: - npm config: [code block] ; "user" config from C:\Users\Bilal\.npmrc registry = "http://registry.npmjs.org/" ; node bin location = C:\Program Files\nodejs\node.exe ; cwd = C:\Users\Bilal ; HOME = C:\Users\Bilal ; Run `npm config ls -l` to show all defaults.

Support override keyword on class methods

(Update by @RyanCavanuagh) Please see this comment before asking for "any updates", "please add this now", etc.. Comments not meaningfully adding to the discussion will be removed to keep the thread length somewhat reasonable. ------ (NOTE, this is _not_ a duplicate of Issue #1524. The proposal here is more along the lines of the C++ override specifier, which makes much more sense for typescript) An override keyword would be immensely useful in typescript. It would be an optional keyword on any method that overrides a super class method, and similar to the override specifier in C++ would indicate an intent that "_the name+signature of this method should always match the name+signature of a super class method_". This catches a whole range of issues in larger code bases that can otherwise be easily missed. Again similar to C++, _it is not an error to omit the override keyword from an overridden method_. In this case the compiler just acts exactly as it currently does, and skips the extra compile time checks associated with the override keyword. This allows for the more complex untyped javascript scenarios where the derived class override does not exactly match the signature of the base class. Example use [code block] Example compile error conditions [code block] IntelliSense As well as additional compile time validation, the override keyword provides a mechanism for typescript intellisense to easily display and select available super methods, where the intent is to spe

Add functionality for allow self-hosted runner to protect workflow file and allow only execution only for collaborators for PRS

Description: Hi all, first of all I really like the github action runner and self-hosted runner. It has however an issue with working for `pull-request` workflows. I think the runner should have a way to be configurable to run only on Pull-requests from collaborator of X org or Repo. The problem to be solved is to protect the github-workflow file and don't be changed by any arbitrary PR ( so there is no output redirection or other code executed) it is a recurring topic in some forums, but there is no solution or any issue about this afaik. let me know, and ping me for any info . best

The inferred type of "X" cannot be named without a reference to "Y". This is likely not portable. A type annotation is necessary.

Bug Report 🔎 Search Terms inferred type cannot be named, symlink node_modules 🕗 Version & Regression Information I'm verifying the problem on the `typescript@4.1.3`. I've not tried older versions but at least is also reproducible on the `@next` version as of today. It is probably a regression or a corner case related with other issues opened and already closed like: - https://github.com/microsoft/TypeScript/issues/30858 - https://github.com/microsoft/TypeScript/issues/28689 - https://github.com/microsoft/TypeScript/issues/2338 - https://github.com/microsoft/TypeScript/issues/29221 ⏯ Playground Link Link for a repo where the problem is being reproduced > NOTE: Just clone the repo and run `yarn tsc` 💻 Code All the relevant code can be found at https://github.com/mistic/reproduce-typescript-problem-when-symlinking-node_modules It is just reproducing a similar setup that I had on other project that was generating the problem: - node_modules are a symlink to another location that is not a direct parent of the symlinked node_modules - we are using types in the compilation from a library where those types are just exported from other one, like for example `withRouter` within `react-router-dom` that is just a plain export from the same type on `react-router`. 🙁 Actual behavior I got the following error: [code block] 🙂 Expected behavior I was expecting no error at all and that the typescript compiler was just able to find all the respective modules. I've tried ev

Provide a way to add the '.js' file extension to the end of module specifiers

In order to use es6 modules in the browser, you need a .js file extension. However output doesn't add it. In ts: `import { ModalBackground } from './ModalBackground';` In ES2015 output: `import { ModalBackground } from './ModalBackground';` Ideally I would like this to be output `import { ModalBackground } from './ModalBackground.js';` That way I can use the output in Chrome 51 [code block] Related to https://github.com/Microsoft/TypeScript/issues/13422

Discussion: (Reflective) Type Model

Hi all, We currently have a AST model for TypeScript which is useful for compilers, editors, and linters. However, it would be extremely useful to have a type model, a la Java's reflective model. There are a huge number of use-cases supporting this, but I will list a few here: - I have a REST interface and I define a data model for it as a TypeScript interface. I use this interface for the function definition of the REST implementation, but then use the type model to validate the input at runtime. - I have a service model that abstracts an interface for some system (database, or application, etc.). I define this as a TypeScript interface (maybe with some decorators as meta-data), and have a generator library that extracts this information to either generate code - or create a runtime implementation - that actually implements the service. - I have an injection (DI) system. I use injection decorators on class properties/constructor parameters, and use the type model to reflectively wire the correct instance. A good example of what could be achieved with this, is something like the Spring platform for Java where our applications are built as decorated components and most of the boilerplate code is abstracted away by the platform thanks to reflection and decorators. I have a "first stab" at implementing such a thing: typescript-schema. It's not feature complete and the design isn't finished either. But hopefully it gives a feel for what a reflective model could look like. Is

Support for NodeJS 12.7+ package exports

NodeJS 12.7 added support for a (currently experimental) feature for custom package imports and exports in `package.json`: https://github.com/jkrems/proposal-pkg-exports/ In short, this feature allows a package author to redirect exports in their package to alternate locations: [code block] This is currently only available when `--experiemental-exports` is passed to NodeJS, however we should continue to track the development of this feature as it progresses.

Path mappings based module resolution

Proposed module resolution strategy UPDATE: proposal below is updated based on the results of the design meeting. Initial version can be found here. Primary differences: - instead of having `baseUrl` as a separate module resolution strategy we are introducing a set of properties that will allow to customize resoluton process in existing resolution strategies but base strategy still is used as a fallback. - `rootDirs` are decoupled from the `baseUrl` and can be used without it. Currently TypeScript supports two ways of resolving module names: `classic` (module name always resolves to a file, module are searched using a folder walk) and `node` (uses rules similar to node module loader, was introduced in TypeScript 1.6). These approaches worked reasonably well but they were not able to model _baseUrl_ based mechanics used by RequireJS or SystemJS. We could introduce third type of module resolution that will fill this gap but this will mean that once user has started to use this new type then support to discover typings embedded in node modules (and distributed via `npm`) is lost. Effectively user that wanted both to use `baseUrl` to refer to modules defined inside the project and rely on `npm` to obtain modules with typings will have to choose what part of the system will be broken. Instead of doing this we'll allow to declare a set of properties that will augment existing module resolution strategies. These properties are: `baseUrl`, `paths` and `rootDirs` (`paths`

package 404 not found

What / Why Your package manager couldn't get any packages. (404 not found) When Now Where npm public registry How n/a Current Behavior 404 not found

Type checking/VS Code slow when using MUI

TypeScript Version: 3.8.0-dev.20191029 Search Terms: mui, material-ui, typescript, slow Example Project https://github.com/jdoklovic/mui-slowness Expected behavior: Make a bad change to something in src/react/pages/Main.tsx autocomplete seems to be speedy, and error reporting should be too. Actual behavior: Takes forever to see errors Related Issues: #32085, #32229, #31817, #30908 Not exactly sure what's going on, but the error reporting in VS Code is super slow. I've made sure I'm using specific named imports, and I've even forked MUI and mad all of the internal code so the same and removed things like import from '..' but it didn't seem to help. Here's the output from tsserver logs which doesn't seem to contain anything that jumps out at me. Also note, I'm using typescript-eslint with the VS Code ESLint extension, not tslint, but eslint seems to be pretty fast. mui-slowness-tsserver.log

Suggestion: minification

TypeScript should support emitting minified JavaScript. There are several different things we could support: 1. Just remove whitespace 2. Minify unobservable identifiers 3. Remove provably dead code 4. Whole-program minification (i.e. closure compiler) 5. (Others?)

Allow enums of types other than number

I'm reopening this issue, because it was closed with the move from codeplex, and doesn't seem to have been re-opened. https://typescript.codeplex.com/workitem/1217 I feel like this is very important for a scripting language.-- Especially for objects that are passed back and forth over web service calls.-- People generally don't use integer based enums in json objects that are sent over the wire, which limits the usefulness of the current enum implementation quite a bit. I would like to re-propose the original contributor's suggestions verbatim.