DEV Community: Dan Walsh

[SOLVED] Vue 3 + TypeScript + Inlay Hint support in NeoVim

Dan Walsh — Tue, 19 Nov 2024 03:45:52 +0000

It would be an understatement to say that getting stable Vue 3 language server support in NeoVim over the last 9-12 months has been smooth sailing for me, as evidenced by this lengthy GitHub issue: volar v2 no longer works.

I'd almost given up on finding "the right" solution. Everywhere I looked, others had "solved" the issue in different ways: they were using the vtsls TypeScript LSP wrapper instead of ts_ls, or they were using coc.nvim, or the now-archived null-ls.nvim. But nowhere could I simply find a reliable configuration for a Vue language server configured natively in NeoVim.

But today, I've finally got it working, and it looks like it should be for good. Massive thanks to Johnson Chu and GR3YH4TT3R93. 👏

Now I can finally say:

TLDR, just gimme the config so I can write some sweet Vue code with that LSP-goodness

Since you asked so nicely, sure. Here are the volar and ts_ls server configs for nvim-lspconfig. If you're using something like kickstart.nvim, you'll want to add these entries to your servers table:

local servers = {
  -- Vue 3        
  volar = {},
  -- TypeScript
  ts_ls = {
    filetypes = { 'typescript', 'javascript', 'javascriptreact', 'typescriptreact', 'vue' },
    init_options = {
      plugins = {
        {
          name = '@vue/typescript-plugin',
          location = vim.fn.stdpath 'data' .. '/mason/packages/vue-language-server/node_modules/@vue/language-server',
          languages = { 'vue' },
        },
      },
    },
  },
  -- ...
}

And for bonus points, here's the config if you want inlay hints. For this to work we need to disable hybrid mode:

local servers = {
  -- Vue 3        
  volar = {
    init_options = {
      vue = {
        hybridMode = false,
      },
    },
    settings = {
      typescript = {
        inlayHints = {
          enumMemberValues = {
            enabled = true,
          },
          functionLikeReturnTypes = {
            enabled = true,
          },
          propertyDeclarationTypes = {
            enabled = true,
          },
          parameterTypes = {
            enabled = true,
            suppressWhenArgumentMatchesName = true,
          },
          variableTypes = {
            enabled = true,
          },
        },
      },
    },
  },
  -- TypeScript
  ts_ls = {
    init_options = {
      plugins = {
        {
          name = '@vue/typescript-plugin',
          location = vim.fn.stdpath 'data' .. '/mason/packages/vue-language-server/node_modules/@vue/language-server',
          languages = { 'vue' },
        },
      },
    },
    settings = {
      typescript = {
        tsserver = {
          useSyntaxServer = false,
        },
        inlayHints = {
          includeInlayParameterNameHints = 'all',
          includeInlayParameterNameHintsWhenArgumentMatchesName = true,
          includeInlayFunctionParameterTypeHints = true,
          includeInlayVariableTypeHints = true,
          includeInlayVariableTypeHintsWhenTypeMatchesName = true,
          includeInlayPropertyDeclarationTypeHints = true,
          includeInlayFunctionLikeReturnTypeHints = true,
          includeInlayEnumMemberValueHints = true,
        },
      },
    },
  },
  -- ...
}

Note: this assumes you are using mason.nvim to install and manage your LSPs.

With that in place, you should be able to do all the good things: code completion, go to definitions, rename symbols across files, and tell your co-workers you use NeoVim btw.

So how did we get here?

I'm glad you asked.

The previous Vue language server versions Vetur and Volar v1 were both troubled with memory duplication issues and the additional complexity of requiring the TypeScript Vue Plugin.

Both the TypeScript language server and the Vue language server were creating duplicate TypeScript abstract syntax trees (AST) in memory, which scaled with the size of your project.

While the TypeScript Vue Plugin had neat features like renaming symbols across .ts and .vue files, it added yet another layer of memory usage.

All of this lead to performance issues and tooling trade-offs, amounting to a sub-optimal development environment.

The solution at last

However, through much hard work and determination, Volar's author Johnson Chu delivered Volar v2 and a new "Hybrid mode" which solves these problems!

Johnson has a great write up on the history of these issues, including some useful visual aids. I would highly recommend you read it.

And it was GR3YH4TT3R93's support and patience in this GitHub issue thread, helping find the right configuration to support not just the newly released Volar v2, but inlay hint support as well.

TailwindCSS is great; why so much hate?

Dan Walsh — Thu, 02 Feb 2023 00:35:36 +0000

I see way too many articles about why TailwindCSS is bad, or wrong, or bloated, or [insert-your-negative-adjective-here]. Absolutely, you should follow the rule "Horses for courses"—use the right tool for the right job. But the majority of these articles (that I've read) seem to repeat the same anti-utility-CSS talking points such as "HTML bloat" and "repetition is bad".

Let's respond to one such article, by @gravy59. You should read their original post in full.

🚨 Before we jump in

Please read this with the intention that it was written, as a rebuttal to the original post. The goal here is to provide devs (both starting-out and experienced) with multiple views on a topic, so they can make more informed decisions about the technologies and practices they choose to invest their time in.

🤦‍♂️ Atomic classes are essentially inline styles

Tailwind's config file allows you to create any number of CSS properties, and their new JIT arbitrary values are essentially inline css

This is false. Arbitrary values (and even arbitrary properties and variants, for that matter) are superior to inline styles in that you can use modifiers such as hover: or even media queries, all without having to leave your HTML. Is it recommended that you use arbitrary values/properties/variants liberally? No—you should stick with your preconfigured design system wherever possible. This is a niche tool for things such as unique design elements.

This can sometimes result in massive, bloated class names that are not that better than inline styles.

Again, as above, it is unfair to conflate inline styles with class names. And if you're struggling to read your TailwindCSS class names, make sure you have the Prettier class sorting extension installed.

🤦‍♂️ BEM is a better choice for reusable components

Tailwind isn't as friendly to reusable components compared to something like BEM.

I would argue that BEM works against reusable components, in that at its core you are required to name "things"; arguably one of the most difficult and time consuming things a dev might have to do. Unless you have thought through every possible abstraction and mutation of your technical requirements, you're going to run into cascading and inheritance issues.

Moreover, BEM can lead to premature abstraction and the creation of unique single-use modifier classes to target edge cases. Sarah Dayan has a great write up on this.

🤦‍♂️ Repetition is bad

Their solutions are flimsy at best. They recommend that you
A) Use a framework, which not all developers want to do, or
B) extract styles with their @apply directive, which do anything about the problem Tailwind was intended to solve.

Don't forget the very first solution in their documentation: Using editor and language features. IDE tools such as multi-cursor editing and language template loops are powerful and quick enough to deal with repetition. Selecting the class and pressing Cmd+D or Ctrl+D a few times on your keyboard is super simple, effective and, in most cases, all you need:

🤦‍♂️ Avoid HTML file-size bloat at all costs

The first solution works fine from a workflow standpoint, but at compile time you're still left with bloated class names (even if Tailwind purges unused css) that in some cases can balloon file sizes.

This is another one of those myths that keeps circling the drain, but threatens to linger on forever more. Sarah covers the "HTML class names bloat" myth succinctly in her article. The TL;DR version is:

Gzip was made to handle duplicate strings.
Trimming your HTML classes will make little to no difference in your final request size.
"HTML bloat" doesn't matter, but "CSS bloat" does.

📣 Don't take my word for it

I would highly recommend you subscribe to and check out Theo's content on YouTube. Theo is a massive advocate for TailwindCSS, and for good reason.

Below is just one of his videos debunking TailwindCSS myths and providing his sound reasoning for continuing to use it to implement his design systems:

👍 At the end of the day, use what works

I've said it before and I'll say it again: "Horses for courses" 🏇

Sometimes, TailwindCSS is going to be a great tool for the job, maybe even the best tool. Other times, plain CSS is going to do the trick nicely, or perhaps a CSS superset like SCSS. Or maybe Styled Components are going to deliver greater "bang for buck", given your project's technical requirements.

Ultimately, use what works for you, and for your project. But let's make sure we're not misrepresenting the tools we choose not to use.

Peace 🕊️

I thought I'd share two dev wallpapers with you

Dan Walsh — Fri, 25 Nov 2022 13:24:34 +0000

Felt randomly inspired to create a couple of JavaScript-based wallpapers this evening, and I thought that I might post them here for you guys. I used the fantastic website https://ray.so/.

They're a bit on the philosophical side, a little bit whimsical, so take them as they are.

I hope your coding projects are inspiring you in new and wonderful ways ✌️

practice-makes-better.js (Download hi-res)

life-event-handler.js (Download hi-res)

Why FontAwesome is still awesome

Dan Walsh — Wed, 08 Jun 2022 01:54:42 +0000

I read an interesting post in which the author stated the reasons why they were officially done with FontAwesome. I was intrigued, given I use FontAwesome in all my projects and feel that I am familiar enough with its various implementations.

To my surprise, the reasons provided all revolved around one core issue—improper production implementation. It seemed a little unfair to negatively review FontAwesome as a whole based on improper or impractical implementations. That would be like giving negative reviews to a toaster manufacturer because lots of people set up their toasters in their bathrooms (and were met with unfortunate accidents). It’s not a failing of the manufacturer...

FontAwesome can be implemented in many ways such as using Kits, downloading and hosting the SVG files, and my personal favourite: importing the FontAwesome npm packages into your project and using the Library for selective icon importing.

Developers should rarely be hosting and linking the entire suite of FontAwesome CSS files in a production application or site (unless they are happy to accept the pitfalls that go along with it, or if it's necessitated by the project's requirements). But to be clear: this is not the optimum nor the recommended implementation approach, and as such, it shouldn’t be used as the yard stick to measure the practicality and usefulness of FontAwesome as a whole.

Let's address the points in the original post...

🙅‍♂️ Myth #1: Managing versions is nightmare

The premise:

[You're] building a website in 2018, you may have used FontAwesome 5. [...] Let's say you need a gameboy icon. [...] But it doesn't work. Here's all the reasons why.

Here we go...

REASON 1: You're on FontAwesome 5.0. And this is on FontAwesome 5.11.0.

If implemented as project dependencies using npm, a quick update to your FontAwesome packages will provide you with all the latest icons.

Alternatively, if you've implemented a Kit, all of the latest icons will be available to you, based on your selected version. You easily can check and update the version of your Kit by logging into your FontAwesome account.

REASON 2: This is a 'pro' font. You're using a free version.

When searching for icons to use on the FontAwesome website, just click on the “Free” filter so you only list the icons available to your project.

REASON 3: You've been importing solid versions of fonts. You should You need the light versions.

So then install the light-style npm package and import the icons you need.

Better yet, if you've implemented FontAwesome as a Kit, then you automatically have access to every single icon style.

🙅‍♂️ Myth #2 - You import thousands of unused icons

The premise:

How many icons are you really using on your site? Maybe 6 or 7? Most sites (and I'm speaking from my own background) only use a handful of icons. [...] If you're importing a fontAwesome's regular.css, you're bringing in hundreds of fonticons you don't need. It's even more nightmare-ish if you're getting a circle-question icon (which lives in regular.css) AND a Facebook icon (which lives in brands.css). Now there's thousands of fonts imported... all eating bandwidth.

Again, if set up optimally, only the very few imported icons you are actually using (and their supporting CSS styles) are added to your final transpiled build files.

Reading further:

Defenders may say, "Well you can tree-shake it" or "optimize it".

And you're right! So... how many devs even know to do that or have the gumption to set that up?

Some common ground! While I was glad to hear that the author agreed that the defenders are right, I was taken aback by the assumption that implementing FontAwesome optimally is some Herculean task beyond the ability and understanding of most devs.

Lastly:

TailwindCSS includes the entire kitchen sink as well. But they also include helpers to prune it all so you ship the absolute, smallest most performant css you can.

The comparison to TailwindCSS is moot, given that FontAwesome provides the same optimisation options out of the box, provided your chosen implementation method supports it. For example, using npm packages and importing select icons ensures only the relevant icon data and CSS is included in your transpiled build.

And using Kits means none of this data is included in your final build and the specific CSS and SVG data is sent to the user during the client-side render of the page.

🙅‍♂️ Myth #3 - Resizing the icons is a nightmare

The premise:

A major problem with font icons is that you're treating them like fonts first, not icons. You want a horse icon to be 100px wide. This won't work: .fa-horse { width: 100px; /* does nothing */ }.

Instead, you have to fiddle with this using font-size.

That also means these icons are also affected by other css text modifiers, like line-height.

FontAwesome uses the font-size property because the icons are sized relative to the content and UI elements surrounding them. When you place a contextual icon next to your button label, it’s great that the icon will automatically match its size with that of the button label text. Need the icon to be a little bigger? Just add the fa-lg class.

A quick skim over the documentation will tell you everything you need to know about sizing your icons.

🙅‍♂️ Myth #4 - Major version releases break compatibility across the board

The premise:



<!-- FontAwesome 3 -->
<i class="icon-star"></i> 

<!-- FontAwesome 4 -->
<i class="fa fa-star" aria-hidden="true"></i>

<!-- FontAwesome 5 -->
<i class="fas fa-star"></i>

<!-- FontAwesome 6 -->
<i class="fa-solid fa-star"></i>

If I wanted to upgrade FontAwesome 3 to FontAwesome 6, I'll have to go find all the markup and fix that.

If someone is using FontAwesome 3, sure, they would have to do that.

However, from FontAwesome 4 and up, backward compatibility is built in. You can upgrade your v4 or v5 project to v6 without having to make any changes to your markup.

If you check out the “Backward Compatibility” section of the “What’s Changed” section of the documentation, you’ll find that support for the use of the old style syntax (and even old icon names and Unicode values) comes out of the box.

🙅‍♂️ Myth #5 - You have to upgrade your plan to get the latest icons

The premise:

If I have FontAwesome 5 Pro, which I purchased in 2019, and I wanted a [thin-style bagel icon], I'll have to either:

Option 1: Keep FontAwesome 5 Pro and also include FontAwesome 6 [thin-style icons]
Option 2: Buy FontAwesome 6 Pro.

Just to get a [bagel icon], I now can either fracture my versions or pay $99.

The answer is easy: just use the icon! A pro plan with FontAwesome includes the use of any icon in the latest version, always. So when v7 inevitably gets released, you’ll get access to those icons too, no plan-upgrade or additional payments required.

In Summary

All of these problems do have workarounds. The thing is -- all these problems are strictly from using FontAwesome!

This is almost true. I would go further to say that “all these problems are strictly from implementing FontAwesome in an unoptimised manner”.

When implemented well, FontAwesome provides you with lean, accessible, scalable icons for your projects. The original post conflated the issues present in bloated and “quick” implementations with the service as a whole, which I feel misinforms people of its great many utilities when used appropriately.

In my eyes, FontAwesome is still awesome.

☝️ Remember: Always import just the icons you need, tree-shake your projects, and never make toast in the bath.

💬 What do you think? Have you worked on a project that implemented FontAwesome in a not-so-awesome way? What's your favourite method for adding icons to your projects? I'm keen to hear your perspectives and thoughts in the comments below!

This post was originally a comment that I wanted to expand into a more long-form response. You can view the original post and my comment here:

Post: https://dev.to/rockykev/im-officially-done-with-fontawesome-2h2f

Comment: https://dev.to/danwalsh/comment/1p8e4

Bootstrap 5 + React project setup and customisation

Dan Walsh — Mon, 14 Dec 2020 07:28:34 +0000

With the recent release of Bootstrap 5 Beta 1, now is a great time to dip your toes into working with the new major updates and getting your tools ready for when the final release drops.

Setting up your project 🗂

1. Set up your environment 🌳

Initialise a new npm package in your directory:

$ npm init -y

The -y parameter tells npm to accept the default answers for all options.

Next, install our packages:

$ npm i bootstrap@next react react-dom next sass

This will install:

bootstrap@next -- Bootstrap 5 Beta
react -- React
react-dom -- React DOM
next -- NextJS
sass -- SASS/SCSS preprocessor

We also need to set up our scripts in package.json as follows:

{
  // ...
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start"
  },
  //...
}

2. Add your SCSS file 👨‍🎨

Next we need to add our SCSS folder and file:

$ mkdir scss
$ touch scss/main.scss

And add the following content to scss/main.scss:

// Import Bootstrap 5 Beta!
@import "~bootstrap/scss/bootstrap.scss";

3. Set up your pages 📄

We need to set up our usual index page, but also a custom App component that lives within the /pages directory. This is so we can ensure that Bootstrap 5 Beta is loaded across the entire NextJs app.

Create your pages folder, the index page and custom App component:

$ mkdir pages # Your pages folder
$ touch pages/index.js # The index page
$ touch pages/_app.js # The custom App component

In the pages/index.js file, add the following:

const IndexPage = () => {
  return "Hello world!";
};

export default IndexPage;

And in your pages/_app.js file, add the following:

import "../scss/main.scss";

function MyApp({ Component, pageProps }) {
  return <Component {...pageProps} />;
}

export default MyApp;

At this point you can run npm run dev in your terminal and browse to http://localhost:3000/ in your web browser and you'll be greeted with the universal dev message "Hello world!".

Now for the fun part...

Customising Bootstrap 🎨

So we've got our project up and running, our dependencies are all installed and ready roll, and Bootstrap is being imported into our main SCSS file.

Let's add some structure and a little content to our index page:

const IndexPage = () => {
  return (
    <div className="container">
      <div className="row">
        <div className="col">
          <h1 className="mt-4">Hello world!</h1>
          <p>This is Bootstrap 5 Beta + NextJS</p>
          <button className="btn btn-primary me-2">Read the docs!</button>
          <button className="btn btn-outline-secondary">
            or just get started
          </button>
        </div>
      </div>
    </div>
  );
};

export default IndexPage;

This will render our new content within Bootstrap's fully-responsive mobile-first grid system:

We can then override Bootstrap's SCSS variables to build our our theme:

// Change the primary colour
$primary: rgb(207, 44, 4);

// Set the sans-serif font
$font-family-sans-serif: Arial, sans-serif;

// Maybe set a difference heading font family
$headings-font-family: Georgia, serif;

// Make headings bolder!
$headings-font-weight: 700;

// Thicken up our borders
$border-width: 3px;

// Remove the border-radius everywhere
$border-radius: 0;

// Import Bootstrap 5 Beta!
@import "~bootstrap/scss/bootstrap.scss";

Which should give you something like this:

That should be enough to get your next Bootstrap 5 + NextJS web app kick started.

Now get out there and make something beautiful!

Self-host Google Fonts in your next React project with Fontsource

Dan Walsh — Sat, 12 Dec 2020 12:25:02 +0000

The situation 🤔

While you can rely on Google's CDN to host and serve your fonts so you don't have to, you're relying on that connection and the fonts themselves being available. That's fine for a quick mock-up, but not so great for your production roll-out.

Typefaces—the status quo 👌

The Typefaces project has been the long-standing approach to self-hosting Google fonts with your React web apps, but it wasn't without its caveats, as explained in the opening lines of the project's README.md:

The Typefaces project is now deprecated.

@DecliningLotus created FontSource which provides the same functionality as Typefaces but with automated releases & richer support for importing specific weights, styles, or language subsets.

Enter, Fontsource 🙇‍♂️

With Fontsource, you get a number of great benefits right out of the gate:

Ridiculous performance gains from self-hosting (source, source).
Version locking ensures your fonts are free from Google's tinkering.
Your fonts will be available even if your React app is running offline.
Fontsource also includes Open Source fonts, not just Google's library.

Why are we still talking about it? Let's use some fonts already!

Using Fontsource with React 🔤

As an example, let's use the Google Font "Poppins".

A note from the installation docs:

Fontsource assumes you are using a bundler, such as Webpack, to load in CSS. Solutions like CRA, Gatsby and Next.js are prebuilt examples that are compatible.

Now, on to the fun part:

In your project directory, install the font:
```
npm install @fontsource/poppins
```

In your app or index JS file, import the font:

import "@fontsource/poppins" // Defaults to weight 400 with all styles included.

Alternatively, in your project SCSS file, prepend the following to the top:

@import "~@fontsource/poppins/index.css"; // Defaults to weight 400 with all styles included.

Lastly, use the font in your CSS/SCSS rules:
```
body {
font-family: "Poppins";
}
```

And that's it!

As long as your chosen font supports it, you can optionally import other subsets that you need, for example:

@import "~@fontsource/poppins/700.css"; /* Font-weight 700 */
@import "~@fontsource/poppins/600-italic.css"; /* Font-weight 600 italic */

But do they have x font? 🙄

Fontsource has an amazing search directory that lists all supported fonts. It also allows you to interactively adjust font-size on the fly.

Better still, every font page lists the npm installation commands and JavaScript/SCSS import scripts needed to get you up and running in seconds.

You now have all the knowledge you need to make your React app beautiful with any self-hosted font you could want (aside from comic-neue and lobster, because you want your React app to look beautiful, right? 😅).

Cover photo source: Photo by Marcus dePaula on Unsplash

Edit 30/08/2021: Updated Fontsource package names (as they were moved from fontsource-[font] to @fontsource/[font].
Edit 30/08/2021: Updated Fontsource links (thank you, @jerhowden! 🙇‍♂️)

Flush your DNS cache with a single easy-to-remember command

Dan Walsh — Fri, 11 Dec 2020 04:02:44 +0000

The problem 🙄

Has this ever happened to you?

You're working away merrily on your web project and you've just made a DNS change—maybe you've added a new subdomain or you're now redirecting site traffic through a Web Application Firewall (WAF). But... your browser still thinks it can find your web project at the old IP address. You could wait until the time-to-live (TTL) expires on the DNS records you changed, but you've got a deadline to meet. Now you'll have to scour the web for another mac flush dns article...

Because it happens to me all the time!

The solution 👍

I figured it was time that I made my life just a little easier and create a system-wide bash script that I could invoke from any user account on my Mac.

Now when I want to flush my DNS, all I need to do is open a Terminal window and type:

$ flush-dns

NOTE: This works on MacOS Catalina and MacOS Big Sur. Be sure to replace the DNS flushing commands in my example with those relevant to your OS and version.

How to do it 🧐

Open up Terminal.
Enter the following commands:

$ cd /usr/local/bin
$ echo "sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder && echo \"DNS cache flushed successfully\"" > flush-dns
$ chmod +x flush-dns

Close and relaunch Terminal.

Testing it out 👨‍🔬

Now the moment of truth!

In your freshly opened terminal window, type in flush-dns and hit Enter.
Terminal will prompt you for your password as it needs to elevate privileges via the sudo commands—type it in and hit Enter again.
Terminal will then execute the DNS cache flushing commands we added earlier—perfect!

Don't forget! — You might also need to clear your browser cache and restart your browser for the script to take effect!

Cover image source: macrovector @ www.freepik.com