The articles:
Here's a quick analogy to help visualize the difference between using Visual Studio and Visual Studio Code. Imagine you need to build a bookshelf. You can pop into Ikea, select a few shelf unit to suit your needs, add a few accessories, and then spend an hour or two at home assembling the units. All the instructions and the fittings are in the kit. Alternatively you can build from scratch, selecting the wood, learning to use the right tools for each task, choosing the hardware from the huge available range of screws & bolts & brackets. Along the way you gain skills with the tools, and create something totally customized for your needs.
No doubt you see where this is leading.... Starting our with VS Code feels a little like an apprenticeship, with so many new techniques and concepts to master. The familiar development workflow in Visual Studio of "New Project..." is replaced when using VS Code by decisions of what tools and facilities I need in this project, and what build steps will be appropriate.
I think this is a good learning process to face. Disrupting our normal routines can be painful at first, but helps make us aware of new and better ways to do things. Core to the new development workflow is npm, the Node Package Manager. This is usually compared to Nuget, but npm is a more vital element in the process than Nuget is in VS.
There is plenty of guidance on the web of how to install Node and npm, so I won't repeat it here (in case you were wondering, Node runs JavaScript code in a background process, and is required if using npm & gulp). I will, however, mention the usefulness of the integrated terminal window in VS Code (CTRL+`) - that has been the place in which I have carried out all the command-line work necessary in my projects.
Starting a New Development Project
Visual Studio Code focusses on files within a folder structure. The tools used within the editor expect files with particular names to be in certain locations in that folder structure - convention over configuration. The general principle when starting from scratch is to create a top level folder for you new development files, open that folder in VS Code, and then run the following:
npm init -y
This creates the package.json file, similar in some ways to the project file in VS - it stores high-level settings for your development project, including the node modules that are used during the development operations.
Tailoring the Development Workflow
Node modules are plugins that can add content to your development project (such as libraries needed in your code). And node modules can also add task handlers to help with the development workflow. We are working here in the open source world, so there are a variety of "competing" options when choosing how to automate and orchestrate tasks in your development process. By this, I mean the ability for the development environment to do such things as check the quality of our source code("linting"), running tests, translate coding languages into runnable formats (compiling or "transpiling"), and packaging the source code for deployment.The main players at the time of writing for creating workflows from these tasks (otherwise known as task runners) are gulp and grunt. An alternative is to use webpack which is a bundling tool that is able to run tasks other than just bundling files. Each takes a different approach to automating tasks. Each can suit different projects, or can seem a better fit for our own way of working. Gulp defines the operations to perform in JavaScript, whereas grunt (and webpack) use configuration files to define the operations.
Using gulp
After some experimentation with webpack and gulp, personally I prefer gulp. It gives me huge flexibility in how I organise the development tasks, is easier to debug through the use of logging statements to explore status of the tasks, and I find it easier to visualize thanks to the low-level step-by-step control. But you may prefer one of the other approaches - as I say, its down to personal preference, as you can probably achieve the same outcomes with any of the approaches. James Nelson provides some useful ideas on this subject.If you choose to use gulp, it is worthy to know that the gulpfile can be written in ES6/ES2015 - this article by Mark Goodyear explains how to achieve this (using babel, and renaming the gulpfile). Why do this? Its another opportunity to become familiar with the new coding styles in ES6/ES2015
In the next installment, I will explain the gulp configuration I have found useful.
No comments:
Post a Comment