Dayne Nienow

Dayne Nienow

1617505680

How to Run JavaScript Code Inside Visual Studio Code

Here’s the most simple way to run JavaScript using Visual Studio Code

Sometimes, you may want to run your JavaScript code immediately inside Visual Studio Code (VSCode) just to see if a piece of code works. The easiest way to run JavaScript using VSCode usually involves installing Node.js locally on your machine so that you can call the script using Node.js.

#javascript #vscode

What is GEEK

Buddha Community

How to Run JavaScript Code Inside Visual Studio Code
Brain  Crist

Brain Crist

1597014000

JavaScript Unit Testing with Visual Studio

Mark Michaelis walks you through the Visual Studio tooling and project setup you’ll need to get the most out of your JavaScript unit testing.

As I detailed in my recent article “A TypeScript Primer,” I, like many developers, have a love/hate relationship with JavaScript. I love JavaScript because of its ubiquity; from iPhone to Android to Windows Phone, JavaScript just works. From iOS to UNIX to Windows, JavaScript continues to just work. (Admittedly, there are some idiosyncrasies, but for the most part – at least from a language perspective – it just works.)

Unfortunately, JavaScript is lacking in its ability to verify intent. It does what you tell it to do – not necessarily what you want it to do. (If you figure out the secret for getting a computer to consistently do what you want rather than what you tell it, please let me know! I would like to partner with you on a business idea or two.) Table 1has a summary of JavaScript’s good and bad:

Table 1. JavaScript, the Good and the Bad

Of all these characteristics, it’s JavaScript’s lack of type safety coupled with not having a compiler fail in the capacity to verify intent. That is, of course, if you don’t have unit tests. Unit tests can compensate for the lack of type safety. And unlike with .NET, where unit tests focus mainly on functional verification (since the compiler eliminated the majority of typos), unit tests in JavaScript do both. In summary, JavaScript unit testing is all the more critical because it’s responsible to not only verify functionality, but also to verify syntax and language semantics.

In this article, I’m going to focus on the Visual Studio tooling and project setup requirements needed to get the most out of your JavaScript unit testing.

Tooling

The two most popular Visual Studio integrated tools for JavaScript unit testing are ReSharper and Chutzpah (a Yiddish word about having the audacity to say things as they are – good or bad). Chutzpah is an open source Visual Studio extension and JavaScript test runner written by Matthew Manela. ReSharper is the well-known JetBrains tool, famous for its C## and JavaScript refactoring capabilities.

Both tools are Visual Studio extensions, so installing either into Visual Studio is nothing more than clicking the Tools->Extensions and Updates… menu and searching for “JavaScript Unit Testing” or simply “Chutzpah” or “ReSharper.”

At the core of most JavaScript unit testing lies a headless browser, PHATOMJS.EXE. When this browser launches, it hosts HTML that in turn references your JavaScript files. In addition to the JavaScript files that you supply from your Web project (and the frameworks like JQuery that you reference as part of your production code), JavaScript unit testing generally relies on a unit testing framework. The two primary unit testing frameworks, both of which are open source, are QUnit and Jasmine. Both are well suited for the task of unit testing but each brings a slightly different style to the unit test. QUnit follows the traditional unit-testing style test format, while Jasmine is a behavioral-driven design (BDD) testing framework.

QUnit

As stated on the QUnit Web site, “QUnit is a powerful, easy-to-use JavaScript unit testing framework. It’s used by the jQuery, jQuery UI and jQuery Mobile projects and is capable of testing any generic JavaScript code, including itself!” Code Listing 1provides a sample QUnit test file.

Code Listing 1: A Sample QUnit Series of Tests

/// <reference path="QUnit.js" />
/// <reference path="../../intellitect.sharepoint.web/scripts/SampleRestService.js" />

var restService = null;
module("SampleRestService.getToken()", {
  setup: function () {
    restService = new SampleRestService("http://IntelliTect.com/Blog");
  },
  teardown: function () {
    restService = null;
  }
});
  test("Provide valid credentials", function () {
    var token = restService.getToken("Inigo.Montoya", "Ykmfptd!");
    equal(token, "ecy8b081wh6owf8o", 
	"The token value returned was not as expected.");
  });
  test("Prevent empty string for the name", function () {
    raises(function() {
      var token = restService.getToken("", "Ykmfptd!");
    }, "Unexpectedly, no error was raised given a blank name.");
  });
  test("Prevent empty null for the password", function () {
    raises(function () {
      var token = restService.getToken("Inigo.Montoya", null);
    }, "Unexpectedly, no error was raised given a null password.");
  });

module("SampleRestService.downloadFile()")
  test("Throw an exception if file does not exist.", function () {
    raises(function () {
      var restService =
        new SampleRestService("http://IntelliTect.com/Blog", 
		"Inigo.Montoya", null);
      var file = restService.downloadFile("Bog.us");
    }, "Unexpectedly, no error was raised given an invalid file.");
  });

As one would expect, QUnit supports the standard unit testing constructs, including grouping tests into constructs (using module), pre- and post-test execution steps (setup/teardown members), and a variety of assertions: ok, equal, notEqual, strictEqual, notStrictEqual, deepEqual, notDeepEqual, raises. Essentially, the structure mimics that of a developer unit-testing library.

Jasmine

Although very similar, Jasmine’s BDD-based API involves defining a Spec – a grouping of tests or conditions to verify. The spec places each test into a context or scenario and comprises a suit of tests (see Code Listing 2).

#visual studio code #visual studio #code #java #javascript

Python в Visual Studio Code

We are pleased to announce that the July release of the Python extension is now available for Visual Studio Code. You can download the Python extension from the Marketplace, or install it directly from the extension gallery in Visual Studio Code. If you already have the Python extension installed, you can also get the latest update by restarting Visual Studio Code. You can read more about Python support in Visual Studio Code in the documentation .

We’ve made 51 improvements in this release, including:

  • Added support for a new language server: Pylance
  • Gather Extension
  • Exporting notebooks to HTML and PDF
  • Debugger connection back

If you are interested, you can explore the full list of improvements in this list changes.

Support for our new language server: Pylance

A couple of weeks ago, we announced the release of Pylance, our new language server based on Microsoft’s Pyright static type checking tool .

Pylance is a fast language server that provides many features to help you write better code, including automatic imports, dead code detection, parameter and return type information, support for a multi-root production environment, and more. You can read the Pylance blog post to learn more about this.

Pylance recently added a context highlighting feature that helps you quickly identify where symbols are being used in a particular file.

You can install the Pylance extension from the marketplace… If you have the Pyright extension installed, you should uninstall it in favor of the Pylance extension to avoid installation conflicts and duplicate errors and warnings, since all Pyright features are included in Pylance.

If you are a Microsoft Python Language Server user, we recommend that you try Pylance. The new language server significantly improves Python IntelliSense in VSCode. Because of this, the long term plan is to eventually ditch the Microsoft Python Language Server as a supported option in the Python extension.

Gather Extension

We are pleased to announce that this release adds support for our new experimental extension, Gather. Gather is a recurring iteration, and we look forward to community feedback to improve Gather’s accuracy! This tool analyzes and identifies required code dependencies in notepad and performs code cleanup, thereby automating this complex and time-consuming task.

You can install Gather on the marketplace today . We’d love to hear your feedback! If you have any problems, feel free to register them in the vscode-python GitHub repository.

#java #javascript #code #visual studio code #visual studio

Brain  Crist

Brain Crist

1595400780

Visual Studio Code May 2020

Welcome to the May 2020 release of Visual Studio Code.

If you’d like to read these release notes online, go to Updates on code.visualstudio.com.

Accessibility#

This milestone we again received helpful feedback from our community, which let us identify and tackle many accessibility issues.

  • The Status bar now supports keyboard navigation. When focus is in the Status bar via Focus Next Part (F6), arrow navigation moves between Status bar entries.
  • To make it easier to start and end selection using the keyboard, there are four new commands:
  • Set Selection Anchor (Ctrl+K Ctrl+B
  • Select From Anchor to Cursor (Ctrl+K Ctrl+K)
  • Cancel Selection Anchor (Escape)
  • Go to Selection Anchor
  • Activity bar entries now have a tab role and set the appropriate aria-expanded state.
  • Aria labels of editors now properly convey the following editor states: pinnedpreview, and readonly.

Workbench#

Flexible layout#

For several iterations, we have announced progress on making our layout more flexible. With this release, that set of features are now ready for general use. Below is an overview of these features.

Moving views between Side Bar and Panel

Perhaps you would prefer a view from the Side Bar to be located in the Panel or vice versa. To do this, you can now drag a view by its header or an entire group by its icon or title from its current placement and move it to the desired location. From the keyboard, the commands View: Move View (workbench.action.moveView) and View: Move Focused View (workbench.action.moveFocusedView) can be used.

Below is a demonstration of dragging Search to the Panel and Problems into the Side Bar.

Moving Views Between Side Bar and Panel

Dragging Search to the Panel and Problems into the Activity Bar

_Theme: _GitHub Light

Earlier there was a setting for moving the Search view from the Side Bar to the Panel and now that setting is obsolete since drag and drop can be used instead.

Grouping views

You might also want to group some views together that come from different extensions or you feel the default groups of built-in views aren’t quite right for you. You can both move views into existing groups or create new groups for a select set of views. This works across the Side Bar and Panel just as before. Below are a couple of examples of this.

Moving Timeline from Explorer to Source Control

Dragging the Timeline view from Explorer to Source Control

Side By Side Debug Console and Watch View

Dragging the Watch view from the Run Side Bar to be next to the Debug Console in Panel

Custom History Group

Creating a custom history group in the Side Bar and Panel with Timeline and GitLens

_Theme: _GitHub Light

Resetting view Locations

Views and groups of views can be reset to their default locations via their context menus. When a view has been moved from its default location, there will be an entry Reset Location to move it back to its home. There are also commands View: Reset Focused View Location (workbench.action.resetFocusedViewLocation) and View: Reset View Locations (workbench.action.resetViewLocations) for resetting all views and groups back to their default locations.

For extension authors contributing views or view containers

When views are moved around the workbench, they sometimes need to be presented differently, either with an icon or extra context if they aren’t in their default location. When contributing a view, authors may now provide an icon property and a contextualTitle. If not provided, these will default to the icon and title of the view container to which they are contributed.

Lastly, extension authors can now start contributing view containers directly to the panel as opposed to activitybar as outlined in the Tree view extension guide.

Pin tabs#

You can now pin tabs either from the context menu or using the new command workbench.action.pinEditor (Ctrl+K Shift+Enter).

Pin Tabs

_Theme: _GitHub Light

Pinned tabs have a number of useful features to help mark files that are important to you:

  • Pinned tabs always appear first before non-pinned tabs.
  • They do not scroll out of view if you have many tabs opened.
  • They do not close when using commands such as Close Others.
  • They do not close even if you exceed a set limit on the number of opened editors.

You can also drag and drop tabs in and out to change the pinned state.

Pinned tabs visually shrink to the size of an icon (or will show the first letter of the filename if icons are disabled) to save space. If you want to see the dirty indicator with pinned tabs, you can set workbench.editor.highlightModifiedTabs: true.

Note: We are still thinking about other ways to present pinned tabs. If you have an opinion, feel free to share your ideas in the existing issues for showing a secondary tab bar or having a setting to show more context for pinned tabs.

Search Editor#

There are several new options for configuring how Search Editors are created:

  • search.searchEditor.defaultNumberOfContextLines - Configure how many context lines a Search Editor shows by default.
  • search.searchEditor.reusePriorSearchConfiguration - Reuse the last active Search Editor’s configuration when creating a new Search Editor.
  • Support for passing Search Editor configuration variables in keybinding arguments (parameter details).

Explorer auto reveal focus without forcing a scroll#

There is a new option focusNoScroll for the explorer.autoReveal setting. When using this option, the Explorer will automatically select files when opening them but will not scroll to reveal them in the Explorer view.

Smooth scrolling for lists and trees#

Enabling the workbench.list.smoothScrolling setting will make scrolling in lists and trees much smoother with hardware that lacks smooth scrolling (for example, discrete mouse wheel on Windows).

Smooth scrolling

Sash size configuration#

You can now use the workbench.sash.size setting to configure the feedback area size in pixels of the dragging area in between views/editors. Set it to a larger value if you feel it’s hard to resize views using the mouse.

Screencast mode font size#

The new screencastMode.fontSize setting lets you configure the font size in pixels that is being used in screencast mode.

Trusted link protection#

VS Code will now allow directly opening URL links to any GitHub remotes in your workspace. Additionally, if you have signed in with GitHub, all links to pages under your GitHub profile will be trusted.

Editor#

Cross file Undo for closed files#

It is now possible to Undo across files, even if the files have been closed in the meantime. The edited files will be reopened and a cross-file operation, such as a rename symbol, will be undone in all affected files.

Unusual line terminators#

VS Code currently recognizes CR (Carriage Return), LF (Line Feed), and CRLF as line terminators. Some programming languages have different definitions for what constitutes a line terminator. This varies across languages, for example LS (Line Separator) and PS (Paragraph Separator) are line terminators in C# and JavaScript, but not in HTML, PHP, or Java. These line ending differences can cause problems when VS Code communicates with a language server, since various concepts are communicated between VS Code and the language server using (line;char) coordinates. If there are different definitions of a line terminator, it can result in different mappings of lines and locations in the file.

When opening a file, VS Code will now check if LS or PS are present in the opened file, and will prompt and ask for permission to remove these characters. These unusual line terminators are rare in practice and are most likely inserted in source code by accident, via copy-pasting.

Integrated Terminal#

Improved link support#

The Integrated Terminal link preview from last month has replaced the old implementation. The new links implementation now enables:

  • Improved web and file:// link detection, by using the editor’s link detection.
  • Folder link support, either opening the folder in the Explorer or opening a new VS Code window.
  • Different link actions for different link types, falling back to “word” links that search the workspace (based on the terminal.integrated.wordSeparators setting).
  • Similar link highlighting and hover experience to the editor.

Terminal with various links

_Theme: _Topaz (Dim)

#visual studio code #visual studio #java #javascript #coding

Brain  Crist

Brain Crist

1595396940

Visual Studio Code June 2020

Welcome to the June 2020 release of Visual Studio Code. There are a number of updates in this version that we hope you will like, some of the key highlights include:

If you’d like to read these release notes online, go to Updates on code.visualstudio.com.

Join us live at the VS Code team’s livestream on Monday, July 13 at 9am Pacific (5pm London), to see a demo of what’s new in this release and ask us questions live.

Insiders: Want to try new features as soon as possible? You can download the nightly Insiders build and try the latest updates as soon as they are available. And for the latest Visual Studio Code news, updates, and content, follow us on Twitter @code!

Accessibility#

This milestone, we again received helpful feedback from our community, which helped us identify and tackle many accessibility issues. Highlights:

  • Compact folders in the File Explorer now properly narrate expanded/collapsed state and the ARIA level.
  • Screen readers can now update the cursor offset in the editor. As a result, the screen reader “Say All” command should work better when stopped and resumed.
  • Same ARIA live messages will now properly be re-read by the screen reader.

Workbench#

Edit object settings from the Settings editor#

Before, the Settings editor could only be used to edit the settings of primitive types, like strings and booleans, and you needed to edit settings.json directly for more complicated settings types. Now, you can edit non-nested object settings from the Settings editor. Extension authors can use this functionality to increase the visibility of these kinds of settings.

Before

In the Settings editor:

Object setting in the old Settings editor

And in settings.json:

Object setting in the JSON editor

After

In the Settings editor:

Object setting in the new Settings editor

Select and keep focus in a list view#

There is a new command, list.selectAndPreserveFocus, which lets you select an item from a list, while keeping focus in that list. This can be helpful if you want to select multiple files from a list, such as the File Explorer, without having focus go to the file editor.

The command is not bound to any keyboard shortcut by default, but you can add your own keybinding:

{
  "key": "ctrl+o",
  "command": "list.selectAndPreserveFocus"
}

Stable Windows ARM builds#

VS Code for Windows on ARM is now available for the stable release! 🎉

Install VSIX through drag and drop#

VS Code now supports installing an extension VSIX file through drag and drop onto the Extensions view.

New Search editor command arguments#

There are two new arguments added to the Search editor commands (search.action.openNewEditorsearch.action.openNewEditorToSide) to allow keybindings to configure how a new Search editor should behave:

  • triggerSearch - Whether a search be automatically run when a Search editor is opened. Default is true.
  • focusResults - Whether to put focus in the results of a search or the query input. Default is true.

For example, the following keybinding runs the search when the Search editor is opened but leaves the focus in the search query control.

{
  "key": "ctrl+o",
  "command": "search.action.openNewEditor",
  "args": { "query": "VS Code", "triggerSearch": true, "focusResults": false }
}

New Search editor context default#

The search.searchEditor.defaultNumberOfContextLines setting has been updated to have a default value of 1 instead of 0, meaning one context line will be shown before and after each result line in the Search editor. To go back to the old behavior, set the value back to 0.

List/Tree: Dynamic horizontal scrolling#

The previously existing workbench.list.horizontalScrolling setting can now be toggled at runtime without forcing you to reload the workbench.

Editor#

Case changing in regex replace#

VS Code now supports changing the case of regex matching groups while doing a find/replace in the editor. This is done with the modifiers \u\U\l\L, where \u and \l will upper/lowercase a single character, and \U and \L will upper/lowercase the rest of the matching group.

Example:

Changing case while doing find and replace

The modifiers can also be stacked - for example, \u\u\u$1 will uppercase the first three characters of the group, or \l\U$1 will lowercase the first character, and uppercase the rest.

Currently, these are only supported in the editor’s Find control, and not in global Find in Files.

Debugging#

New JavaScript Debugger#

Our new JavaScript debugger, after being the default debugger on Insiders last month, is now the default debugger for JavaScript (Node.js and Chrome) in VS Code. If you skipped the “Preview Features” section of the last few VS Code changelogs, you can catch up on the what’s new section of the debugger README.

You should not need to change any settings or launch configurations to take advantage of the new debugger. If you run into any problems, please open an issue!

Single file debugging#

Until today, the VS Code debugger had no standard way of showing that a file in the editor could be easily debugged with just a click of a button. Some debug extensions would allow you to do so, usually with a debug configuration that prompted you to “Debug file in editor.” However, users still had to select the correct configuration in the debug configuration dropdown menu before they can use F5. Other debug extensions implement a fallback strategy for F5: if no launch.json exists, F5 will try to debug the file currently open in the active editor.

Since both approaches are not easily discoverable, some debug extensions (for example, Python) have started to add a Run button to the editor’s title area.

Since we haven’t found a better approach, and this method can be implemented without any need for new APIs, we wrote some guidelines for how to implement it in a standard way. Extension authors can find these guidelines below in the “Extension Authoring” section.

Users need only to remember these icons:

Run and debug action in editor title

If one or both show up on the left-hand side of the editor’s title area, then running or debugging the file in the editor is just one click away.

Less cluttered CALL STACK view#

We’ve started to make the CALL STACK less crowded for common cases: the CALL STACK view now supports hiding debug session nodes that exist for technical reasons, but do not provide much value to users.

The first debug extension that has opted into this feature is the new JavaScript debugger, which could eliminate a parent debug session whenever there is only a single child session.

Screenshot of two "Call Stack" views. Without compaction, there is an extra child session between the parent session and each attached worker processes.

We hope that other debug extensions will follow. Please see the new proposed API below.

New command alias Set Next Statement for Jump to Cursor#

To make the command Jump to Cursor more discoverable for users coming from Visual Studio, we’ve added the command alias Set Next Statement.

If you don’t know what Jump to Cursor does: it lets you move program execution to a new location without executing any of the source code in between.

Breakpoint Path on Hover#

When hovering over a source breakpoint in the BREAKPOINTS view, VS Code now shows the absolute path of the breakpoint.

Tasks#

pnpm package manager support#

pnpm is now a valid choice for the npm.packageManager setting, along with npm and yarn, to run your scripts.

Source Control#

Single view#

The Source Control view has been consolidated into a single view:

Source Control with a single view

All repositories are rendered in a single view, so you can get a better overview of the entire workspace status. Additionally, the Source Control view can now be moved to the panel and other views can be moved to the Source Control view container.

View and Sort#

We have added support for sorting your changes in the source control view by name, path (default), and state when using the list view option. We have consolidated the view options (list vs. tree) and sort options into a new View & Sort menu item in the context menu.

View & Sort in Source Control

Git: Restore squash message#

Similar to usual git merge command, the SCM view will now restore the SCM input with the default message if the user is in the middle of a git merge --squash command.

Languages#

TypeScript 3.9.6#

VS Code now bundles TypeScript 3.9.6. This minor update fixes a few bugs, including one that could cause the TypeScript server to crash on certain source code patterns.

Browser support#

Large file upload support#

You can now upload large files and folders to the web version of VS Code and progress will be reported accurately so that you can track the number of bytes that have been uploaded, as well as the upload speed.

Web upload indicator in bottom Status bar

Towards text file encoding support#

During this milestone, a lot of work went into full support for text encodings in the browser for reading and writing files. We rely on two libraries that are now supported in browsers by leveraging webpack:

  • [iconv-lite](https://github.com/ashtuchkin/iconv-lite) to read and write encodings
  • [jschardet](https://github.com/aadsm/jschardet): to guess encodings from textual content

This work will continue in July and should be generally available soon.

Preview features#

Preview features are not ready for release but are functional enough to use. We welcome your early feedback while they are under development.

Settings Sync#

We have been working the last couple of months to support synchronizing VS Code preferences across machines and this feature is available for preview on the Insiders release.

You can now disable sync on other machine using Turn off Preferences Sync context menu action on the machine entry in Synced Machines view.

Turn off preferences sync for a machine

We’ve also improved progress information when turning on sync.

TypeScript 4.0 support#

This iteration, we’ve continued improving our support for TypeScript 4.0. Some highlights include:

  • Highlight calls to deprecated symbols in the editor with strikethrough
  • Call to a deprecated function rendered in the editor
  • Explain reasons why a given refactoring cannot be applied
  • Displaying the reason a refactoring cannot be applied

#visual studio code #visual studio #java #coding #javascript

COMO USAR e trabalhar com Code Review no Visual Studio Code

Não é todo programador que gosta de compartilhar o seu trabalho ou até mesmo receber feedbacks de como o seu código foi escrito, mas o Code Review é cada vez mais comum em empresas do mundo todo.

Conheça uma extensão para Visual Studio Code e comece a trabalhar com Code Review em seu próximo projeto. Essa é a sua chance de saber COMO USAR e trabalhar com Code Review no Visual Studio Code.

#visual studio code #code review #visual studio #code