Using gulp plugins to transform files
In the last post, I explained how to use tasks, but I didn't explain yet how to make them useful. Tasks are most useful when they automate certain file operations,…
Writing gulp tasks
Now that you know how to get gulp up and running in VS Code, and how to export tasks from your gulp file, let’s talk about tasks themselves. What are they, what are they good for, and how to write them.
Gulp – being a task automation tool – is all about tasks. Anything you do about programming, which is not writing the code itself, can be considered a task, and can very likely be automated. Some tasks are automated already, like compiling your code, building your app. In case of AL development, there are many more already automated tasks, like creating a demo workspace or deploying your app to NAV. If you can automate them, tasks are immensely powerful because they save time and eliminate error.
If you are a web developer, your tasks can include bundling your source files and minifying them. For me, when building pre-2018 control add-ins, most important tasks were bundling source files, zipping the resource file, deploying a control add-in and importing the control add-in using PowerShell. All of these I have automated using gulp, and I’ll explain every single one of them in this series.
But for now, let’s simply take a look at how to write gulp tasks.
Automating control add-in development using gulp
Happy new year everyone! Last year was a bit slow for me, until the very end, when I churned out a year’s worth of posts just in two days. I hope this year to be a bit different, and let me kick-start it with a concept I’ve been playing with recently.
If you are into control add-ins development, chances are you’re familiar with my Visual Studio Project Template for control add-ins. It’s cool because it allows you to deploy all of your changes all the way over to NAV just by pressing F6. But it sucks because it’s based on Visual Studio, which is so… not 2019. It’s true, Microsoft never prescribed exactly which tool you should use to build your control add-ins once you’ve created the interface. It was entirely up to you. For me, Visual Studio used to be the tool of choice because in there you create the interface, and then why not just create everything in there.
But recently, I thought – why not using VS Code to develop control add-ins “v1” (that is: the control add-ins that work in pre-AL, pre-extensions “v2”, pre-NAV2018/BC environments)? If you, like me, still have to do those from time to time, but absolutely want to use VS Code instead of Visual Studio, then this post is for you.
Last month, I’ve decided to port all development work on a major control add-in from Visual Studio into VS Code. When I say “major”, I mean it: it’s 16K lines of JavaScript code in 138 source code files, not including 3rd party libraries. To automate that in Visual Studio, I used a hodge-podge of build tasks, Windows batch scripts, PowerShell scripts, external utilities for zipping and minification, and the first thing I did – stupid, I know – when I transferred all my work to VS Code was to automate all of my tasks exactly the same way. So, I took all the same batch scripts, configured them as VS Code tasks, and I was happy. Not. It was slow, and ugly.
And then I remembered gulp.
It’s funny, gulp should have been the first thing to cross my mind. But, while I knew it was there, I never did anything with it. But, how complicated can it be? It turned out, I was able to replace all of the automation I had earlier into one nice gulpfile.js and turn my entire development experience completely upside-down. It’s that good.
So, I decided to share a little bit of my learning path, lessons learned, hints, tips, tricks, and all else in a series of blog posts about how to automate control add-in development using gulp. This is the first post in the series of an unknown number of posts to follow up.
Disclaimer: this particular post is not a NAV 2018/BC/AL. This is (mostly) for pre-BC control add-in developers. However, a lot of gulp concepts I’ll talk about are readily applicable to AL and BC world.
Is Visual Studio Code really an improvement
Progress often doesn’t look like progress at all when it first arrives.
When on July 3, 1886, Daimler Benz presented his first car, it had a 0.75 horse-power engine that could reach a top speed of 16 km/h. It was able to cover 45 km on a single fuel tank, and it could only take two passengers. Compared to best horse-driven carriages of the day, especially taking the availability of stuff you could use as fuel, this was hardly a progress. Horse-driven carriages bested this car on all fronts, and by large margins.
Imagine what the world would look like today should Daimler Benz heeded the naysayers and mockers of his day, and they were not in short supply.
HelloWorld.al
Finally. Not quite, but still – finally! We finally get the first public glimpse of future of AL code writing, courtesy of Microsoft Dynamics NAV development team.
As you might know, Microsoft is working around the clock to enable new kind of programming for NAV: using Visual Studio Code instead of Microsoft Dynamics NAV Development Environment. They announced it with due fanfare at Directions US, Directions EMEA, and NAV TechDays, and now the NAV community is biting their fingernails off waiting for Microsoft to actually release the thing.
They said some kind of preview will be made somewhat available sometime in December this year, but for now we have got the first glimpse of the new AL syntax.