DEV Community: Hamish Clulee

One Build System - Multiple Vue Apps - Shared Components

Hamish Clulee — Tue, 15 Sep 2020 03:12:02 +0000

How to achieve this and how to maintain developer experience while doing so.

Last updated September 12, 2020

Written with specific references to VueCli v3, but I think a good portion of whats contained within should be applicable across most FE codebases.

The What And The Why

While working on WelcomeQr I was in a position where it made sense to create a seperate app for serving published content at a user's subdomain. So, I started by making a new app scafolled using VueCli located at the root on my current mono repo for the project. Prior to the subdoms app, the repo contained a frontend application and an ExpressJs server for endpoints, database and serving static content (static could possibly have been done faster at the Nginx level, but that's another story, and I'm happy with the current set up). So now I have two seperate Frontend apps, two build systems, two lint configs and I haven't even started writing code yet. Pretty early on in writing the new app I start using components from the main app, at this stage by just copying them into the new directory.

So, that is also the why. I wanted to manage all my frontend code using one build and lint setup (I'm using typescript so linting etc is a little more complex, and therefore makes using one config all the more important.)

Things I Tried On The Road To Completion

I generally start things in a naive manner and that's by no means a negative. I find when I'm attempting something that is new to me making a branch and trying to go directly from A to B has been useful and effective. Sometimes it works first time, other times not so much, this was the latter.

First thing I tried to do was simply make a shared folder at the root of repo and move all the shared code into it, then change the paths in both apps that referenced anything shared. Guess the problem? No linting or typechecking, also my sass variables and the interpolation into each .vue file went to custard at this point.

Ok, so no problems, I'll move the tsconfig file into the root of the project, but then of course I'll need to install some tooling, also my server is running it's own seperate typescript tooling, and that would now be upstream from the new tsconfig. It's quickly becoming obvious that this isn't going to be a quick fix. Time for lunch.

The next thing I tried doing was using two distinct vue.config.[app-name].js files, and the Vue env variable: VUE_CLI_SERVICE_CONFIG_PATH. I found a couple of references to it from the author of this post, who found it buried in the Vue source code, it's not documented, but I looked at the source and it seemed legit - famous last words right?

I did actually think that this would be a winner for a while, but got backed into a corner by realtive paths and needing to have two very different index.html files for each app, I could be wrong here but the results I was getting seemed like a bug in VueCli, of course, because what I'm doing isn't in the docs, it's probably not defined as a bug? Right? ¯\_(ツ)_/¯

The code below is the first attempt at splitting the vue.config.js files, taken from the package.json scripts section.

  "scripts": {

    "serve:main": "env VUE_CLI_SERVICE_CONFIG_PATH=\"$PWD/vue.config.main.js\" vue-cli-service serve main-app/src/main.ts --dest main-app/dist",
    "build:main": "env VUE_CLI_SERVICE_CONFIG_PATH=\"$PWD/vue.config.main.js\" vue-cli-service build --dest main-app/dist main-app/src/main.ts",

    "serve:subdoms": "env VUE_CLI_SERVICE_CONFIG_PATH=\"$PWD/vue.config.subdoms.js\" vue-cli-service serve subdoms-app/src/main.ts",
    "build:subdoms": "env VUE_CLI_SERVICE_CONFIG_PATH=\"$PWD/vue.config.subdoms.js\" vue-cli-service build --dest subdoms-app/dist subdoms-app/src/main.ts"

  },

And the vue.config.main-app.js file.

const path = require('path')

module.exports = {
    chainWebpack: config => {

        // I've ommited stuff that isn't super relevant

        config.resolve.alias.set('@I', path.resolve(__dirname, '../interfaces'))
        config.resolve.alias.set('@shared', path.resolve(__dirname, './shared'))

    }
}

It does work but it produced some strange results, and I think I found a better solution which stayed closer to the documented way of doing things.

The Solution

Apologies for the pre-amble, here is the lamb sauce.

vue.config.js

const path = require('path')

const isMainApp = process.env.APP_TYPE === 'main-app'
const appDir = isMainApp ? 'main-app' : 'subdoms-app'

module.exports = {
    outputDir: path.resolve(__dirname, `${appDir}/dist`),
    chainWebpack: config => {

        // I've ommited all the non-relevant config stuff

        config.resolve.alias.set('@I', path.resolve(__dirname, '../interfaces'))
        config.resolve.alias.set('@shared', path.resolve(__dirname, './shared'))

        config.plugin("html").tap(args => {
            args[0].template = path.resolve(__dirname, `${appDir}/index.html`)
            return args
        })

    },
    devServer: {
        port: isMainApp ? 8080 : 7070
    },
}

package.json

{
  "name": "example config",
  "version": "0.1.0",
  "scripts": {

    "serve:main": "env APP_TYPE=\"main-app\" vue-cli-service serve main-app/src/main.ts",
    "build:main": "env APP_TYPE=\"main-app\" vue-cli-service build main-app/src/main.ts",

    "serve:subdoms": "env APP_TYPE=\"subdoms-app\" vue-cli-service serve subdoms-app/src/main.ts",
    "build:subdoms": "env APP_TYPE=\"subdoms-app\" vue-cli-service build subdoms-app/src/main.ts"

  },
  "dependencies": {
      // deps...
  }
}

folder structure

/
    .git
    .gitignore
    rundev.sh
    deploy.sh
    /front
        /main-app
            /dist
            /src
            index.html
        /subdoms-app
            /dist
            /src
            index.html
        /public
            /images
                logo.png
                ...
            /icons
                check.svg
                ...
        /shared
            /components
                component.vue
                ...
            /api
                auth.ts
                api.ts
            /utils
                seo.ts
        jsconfig.ts
        eslint.js
        package.json
        vue.config.js
    /server
        ...
    /scripts
        bleh.sh
        ....

The Result

One build system, one tsconfig and linting set up, shared code and as many apps as you want all of them able to be run concurrently, and they have their own sass build, pretty neat right? I think this could be used to some awesome effect in larger codebases.

The Drawbacks

One package.json, although this won't affect bundle size, because webpack on bundles whats imported, it could be argued that it will become noisy over time. It's an acceptable issue for me.

Hope you enjoyed reading and found some of this useful.

Wildcard subdomains on digitalocean using Express and Nginx with Let's Encrypt for SSL.

Hamish Clulee — Sat, 12 Sep 2020 00:42:34 +0000

This guide is intended to help you achieve the same thing, but also to keep a record for myself and thirdly to show everyone how smart I am >.< All jokes aside though, I am aware how specific this is as a use case, the hope is that if you are trying to achieve something similar you can cherrypick the bits that are relevant to your mision

The Why and The What

I'm writing an app that allows users to publish simple html at a subdomain, either of their choosing if they pay, or at a randomly generated subdomain if they are cheap.

Original thought process was that once someone published their html from the editor, I could just automate the DNS, SSL and Nginx configurations using some bash and Node packages. The problem is that I'm lazy.

In a flash of inspiration I thought, well I could just set it up so that all subdoamins are valid, then use an HTTP req to check if there should be some HTML served at this subdomain, if so, serve it, if not display a friendly 404 message and suggest that they use the app or check the subdomain.

What follows is a list of the problems I encountered, and the solutions I employed to fix them.

DNS

This was actually super easy, simply add an A record to the digitalocean console and take lunch.

The image isn't great, but just use * as the value and you're good to go.

SSL using Let's Encrypt

Again the eventual solution here was pretty simple, finding the solution wasn't.

sudo certbot certonly 
    --server https://acme-v02.api.letsencrypt.org/directory 
    --agree-tos 
    --manual 
    --preferred-challenges dns 
    -d welcomeqr.codes 
    -d *.welcomeqr.codes

Before Let's Encrypt came to prominence, a humble Frontend dev such as myself would have to go through some small pain and suffering to certify a domain. Now it's straight forward, even for something like the subject of this blog post. In the vast majority of use cases certbot will take care of your Apache or Nginx configs, great for newbs like me, who want to spend time looking at color pallettes and monstrous NPM bundles while combing their beards and drinking artisinal craft beer. The caveat here is that for wildcard certificates you will need to write your Nginx configuration manually.

Certbot is an excellent package provided by Let's Encrypt, honestly top notch, please donate and build statues in honour of Josh Aas, Eric Rescorla, Peter Eckersley and J. Alex Halderman.

Anyway, the mistakes I made while trying to find the certbot command above were as follows:

Trying to add seperate certificates for the wildcard and canonical domain
Searching the interwebs for copy paste examples of the certbot flags that I needed, when I should have just RTFM

Live and learn!

Nginx

Next issue was getting Nginx to serve two different applications, one at the domain, the other at all subdomains. Again, not super difficult, luckily the app served when the user visits any subdomain is just comprised of static files built by vue-cli, but you could do whatever you wanted here by adding a new location block with a value of /

The codeblock below is the only nginx file for the whole site.

server {

    index index.html index.htm index.nginx-debian.html;

    server_name welcomeqr.codes;

    expires $expires;

    location /robots.txt {
            alias /var/www/welcomeqr.codes/server/nginx/robots.txt;
    }

    location /squire/ {
            alias /var/www/welcomeqr.codes/server/squire/;
    }

    location /uploads/ {
            alias /var/www/welcomeqr.codes/server/dist/uploads/;
    }

    location / {
            proxy_pass http://localhost:1980;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-for $remote_addr;
    }

    listen 443 ssl; # This needed to be hand written
    ssl_certificate /etc/letsencrypt/live/welcomeqr.codes/fullchain.pem; # This needed to be hand written
    ssl_certificate_key /etc/letsencrypt/live/welcomeqr.codes/privkey.pem; # This needed to be hand written
    include /etc/letsencrypt/options-ssl-nginx.conf; # This needed to be hand written
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # This needed to be hand written
}

server {
    if ($host = welcomeqr.codes) {
        return 301 https://$host$request_uri;
    } # This needed to be hand written

    server_name welcomeqr.codes;
    listen 80;
    return 404; # This needed to be hand written
}

server {

    index index.html index.htm index.nginx-debian.html;

    server_name *.welcomeqr.codes;

    root /var/www/welcomeqr.codes/front-published/dist/;

    expires $expires;

    listen 443 ssl; # This needed to be hand written
    ssl_certificate /etc/letsencrypt/live/welcomeqr.codes/fullchain.pem; # This needed to be hand written
    ssl_certificate_key /etc/letsencrypt/live/welcomeqr.codes/privkey.pem; # This needed to be hand written
    include /etc/letsencrypt/options-ssl-nginx.conf; # This needed to be hand written
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # This needed to be hand written
}

server {
    if ($host = *.welcomeqr.codes) {
        return 301 https://$host$request_uri;
    } # This needed to be hand written

    server_name *.welcomeqr.codes;
    listen 80;
    return 404; # This needed to be hand written
}

CORS

CORS is a hardship. I had a whitelist, a regex and isDev switch before I started this unit of work. Not too crazy, but far from simple and considering this is a small app which doesnt do much yet... yeah, CORS is a pain. I get it, we need it, XSS and hackers from Russia, fine, but this is my blog so I'm going to complain when I feel like it.

I mentioned that I was working on wildcard subdomains in a Telegram chat full of friends who also happen to be super famous programmers, hence the redaction.

Bascially the browser isn't happy with HTTP requests being fired from a subdomain to a domain without a header named Access-Control-Allow-Origin which matches the origin of the request, where the origin matches the domain and the subdomain. Which is fine if you have a couple of subdomains hardcoded, but if you want the power of the *, then a little extra hackery is required.

// Middleware - this.app = express()

this.app.use((req, res, next) => {

    // tldjs is a handy npm package, 10/10 recommended
    const tld = tldjs.parse(req.header('origin'))

    if (process.env.NODE_ENV === 'production' && tld.isValid && tld.domain === 'welcomeqr.codes' ) {

        // this is the line that does the 'heavy' lifting
        res.setHeader('Access-Control-Allow-Origin', req.header('origin'))

    }

    // other headers and things here have been ommitted becuause security and brevity

    next()
})

// expressjs CORS package
this.app.use(cors({
    origin:
        process.env.NODE_ENV !== 'production' ?
            [DEV_URL, DEV_URL_PUBLISHED, '/\.google.com\.com$/']
            : [PROD_URL, '/\.welcomeqr\.codes$/', '/\.google.com\.com$/'],
    credentials: true
}))

That's it for CORS really, you could do this at the Nginx level as well, but for me this made more sence and does the job well. I can hear confused screaming coming from the security nerds "But now someone can run whatever Javascript they want on a published subdomain, and everyone could die!"

That is true, but all my endpoints are locked up with httpOnly cookies and JWT tokens, also all inputs are santised. I think we are safe, and that tinfoil hat looks a little silly on you.

Conclusion

Everything is easy when you know how. I hope some of the stuff in here helps you, and if it didn't I hope you come away from this thinking about how amazing I am. Probably not on both counts, but dreams are free.

I'm the first to admit that there could well be errors and incorrect assumptions contained in the words and examples above, if you find any and feel strongly about them, reach out to me on GitHub I would appreciate any and all feedback, both negative and positive.

Tips For New VueJs Players

Hamish Clulee — Sat, 12 Sep 2020 00:41:17 +0000

Not using the same name for component file, component template declarations and a components name property

<template>
  <foo-bar-component></foo-bar-component>
<template>

import FooBarComponent from '../components/FooBarComponent.vue'

default {
  name: 'FooBarComponent',
  components: {
    'foo-bar-component': FooBarComponent
  }
}

Component template declarations should be written in the snake-case version of the component file name, the file name should be written in PascalCase.

To convert PascalCase to snake-case, simply replace the capital letters (except for the first!) into hypens:

YouAreAwesome --> you-are-awesome
ThisMakesDebuggingEasier --> this-makes-debugging-easier

Yes - this makes debugging easier, when using VueDevTools, it's much easier to find everything if all the names; file name, name attribute in the component and the component decalration in template blocks, are all the same except for casing.

Not line wrapping

Bad

<div class="warning-subtext">{{firstLetterUpperCase(participant.fullName)}} will not be able to see your message until his/her employer turns Coach Chat on.</div>

Good

<div class="warning-subtext">
  {{firstLetterUpperCase(participant.fullName)}} 
  will not be able to see your message until his/her employer 
  turns Coach Chat on.
</div>

Bad

<div class="survey-popup-card-footer">
  <b-button class="btn-heartbeat small white" variant="secondary" @click="handleHidePopup">BACK TO SURVEY</b-button>
  <b-button class="btn-heartbeat small blue" variant="primary" @click="handleCancelSurveyToDeleteQuestions">CANCEL</b-button>
</div>

Good

<div class="survey-popup-card-footer">

  <b-button
    class="btn-heartbeat small white"
    variant="secondary"
    @click="handleHidePopup"
  >BACK TO SURVEY</b-button>

  <b-button
    class="btn-heartbeat small blue"
    variant="primary"
    @click="handleCancelSurveyToDeleteQuestions"
  >CANCEL</b-button>

</div>

Bad

import { FETCH_EMBER_PATHS, FETCH_EMBER_REVIVE_PATHS, FETCH_EMBER_FILTERED_PRACTICES, FETCH_EMBER_PRACTICES_BY_ID, FETCH_EMBER_PRACTICES_BY_PATHS, FETCH_EMBER_PATH_ELIGIBILITY } from '../../store/modules/embers/constants';

Good

import { 
  FETCH_EMBER_PATHS,
  FETCH_EMBER_REVIVE_PATHS,
  FETCH_EMBER_FILTERED_PRACTICES,
  FETCH_EMBER_PRACTICES_BY_ID,
  FETCH_EMBER_PRACTICES_BY_PATHS,
  FETCH_EMBER_PATH_ELIGIBILITY 
} from '../../store/modules/embers/constants';

Line wrapping is an easy thing to do, it means we can have two or three files open in our editors at a time, it means we can read PR’s without side scrolling, which means reading them faster, it makes code easier to read, and if code is eaiser to read it's easier to debug. If code is well line wrapped, it’s also less likely to contain bugs, because you are not hiding things off screen.

This doesn't need to be done manually, the VSCode prettier extension has really good Vue support and does an excellent job at automating formmating.

Not using the same NodeJ version between code bases

Swicthing between projects should be easy - pull repo, checkout branch, npm install, run dev - write code - should be quick, quick enough that you don't feel like you have to go and make a coffee after you run dev. You should be able to say to any other FE dev, “Run my branch and see what I mean” and they should be able to do this very quickly, having the same Node version is a big part of this.

Generally this problem arises when SCSS/SASS is in use, if you are not using pre-processors, then you can probably ignore this.

Node 12.x is an even version number, which means it's an LTS version, Long Term Stable release. This means bugs in Node get fixed but the Node maintainers. It also means that when we upgrade our build systems, there is one less thing to do.

I suggest using the nvm package, Node Version Manager. Instal it then say nvm current and see the output, if you are interesting in correctness you should see 12.xx.xx or 14.xx.xx. The most importnat thing here is seeing the same across team members.

TL;DR - install nvm then say:

nvm install 12.16.1 && nvm alias default 12.16.1

Not providing a :key when using v-for

For reference and the docs

Basically, if you write a v-for you need to provide a key

    <my-awesome-component
        class="intelligent-reusable-class-name"
        v-for="(value, index) in listOfThings"
        :key="index"
    ></my-awesome-component>

If you read the docs carefully, you will that there are some higher end performance use cases where you would
not use a :key. If you think you have found one of those use cases, contact Hamish to discuss, otherwise, use a :key.

For our purposes, we use the :key every time we use v-for.

Not writing reusable unit's of code or new components

This item is a preview of another post that I am currently writing. Even if you're using a framework like vuetify or
vue-bootstrap (which I don't encourage or agree with, but regardless), that shouldn't mean that you never write new
custom components. Common cases - when using a framework- would be things like wrapper components for commonly used
groups of framework components, if you are often using a set of two or three buttons, write a wrapper component
called HorizontalButtonWrapper, or writing v-if / v-else blocks in a top level router component, use a component to
wrap the logic and reduce the number of lines in the template block.

Anytime you find you self using CTRL+C CTRL+V - write a new component, and reuse code rather than using the same
code twice! One of the main advantages of using an SPA framework like Vue is code reusage. Components are how
that advantage is manifested. It also provides developers the ability to really reduce bundle sizes if used
correctly.

There is a limit to how far you should go, having thousands of files in your repository that are very rarely
used is just another symptom of inexperience or disorganised thinking. But what I have seen much more of is
huge Vue files, with a ton of spagetti code making debugging or refactoring much much slower, and as above,
fully ignoring one of the main benefit's of using Vue in the first place.

The more code you resuse, the less bugs you will create.

The more code you resuse, the less unit tests you will have to write.

The smaller your unit's of code, the eaiser they will be to test.

Anytime you find you self using CTRL+C CTRL+V - write a new function, and reuse code rather than using the same code twice!

Some examples

Bad

<template>
  <div class="row-container">
    <div class="row-item-container one">
      <div class="row-item-actual">{{ someData }}</div>
    </div>
  </div>
    <div class="row-container">
    <div class="row-item-container two">
      <div class="row-item-actual">{{ someOtherData }}</div>
    </div>
  </div>
    <div class="row-container">
    <div class="row-item-container three">
      <div class="row-item-actual">{{ someMoreData }}</div>
    </div>
  </div>
</template>

Good

<template>
  <div
    class="row-container"
    :class="value.className"
    v-for="(value, index) in computedProperty"
    :key="index"
  >
    <div class="row-item-container>
      <div class="row-item-actual">{{ value.data }}</div>
    </div>
  </div>
</template>

default {
  computed: {
    computedProperty() {
      return [
        { value: this.someData, className: 'one' },
        { value: this.someOtherData, className: 'two' },
        { value: this.someMore∂Data, className: 'three' }
      ]
    }
  }
}

Even Better

<template>
  <row-container
    class="row-container"
    :class="value.className"
    v-for="(value, index) in computedProperty"
    :key="index"
    :dataAsProp="value.data"
  ></row-container>
</template>

default {
  computed: {
    computedProperty() {
      return [
        { value: this.someData, className: 'one' },
        { value: this.someOtherData, className: 'two' },
        { value: this.someMore∂Data, className: 'three' }
      ]
    }
  }
}

Anytime you can reduce code reusage, you are actually saving time. Less bugs, less maintenace, making things easier to read and understand for the next guy.

You may think “But it’s faster this way!”

It's not.

It’s faster today, but it means that once you are feature complete, you spend three sprints fixing bugs, instead of a couple of hours. You also learn nothing, which means that next time you have to do the same task, you do the same thing. If you wrote it well the first time, and wrote it in a way that you and everybody else could reuse it - you would be at lunch or at home with your family by now - but instead you’re furiously copy pasting code from somewhere, trying to meet a dead line.

This is real - if you want to move faster - go slower.

Anytime you find you self using CTRL+C CTRL+V - write a new function or a new component, and reuse code rather than using the same code twice!

Another doc about this topic is in the works currently, because this is one of the biggest issues we have in our code bases.

Ignoring warnings from build system, eslint, or VSCode

Believe it or not - warnings exist for a reason!

They exist because, smarter people than us have determined that if we deal with the warning, it will reduce bugs, and if we ignore it….

We will have to spend time fixing bugs.

Warnings are your friends. If you see one, google it. Then fix it. Then commit it and push it. If you can’t fix it get in touch with one of the senior guys to get some help.

The problem that exists currently is that we have so many warnings, they just dont mean anything anymore. Let’s fix that!

Dealing with warnings, from the Developer Console, from Webpack, from NPM and from VSCode extentions really can reduce the amount of time we spend fixing bugs… by a lot.

Try to fix one warning per day. It will make you a happier developer.

Using eslint-disable

Very Bad

// es-lint disable
const someDodgyCode = expressionThatTriggeredAnEslintWarning()

Ok (but very very rare)

return () => {

    // Explain: 'arguments' is a javascript keyword, eslint is wrong
    // Blame: Hamish
    // eslint-disable-next-line no-undef
    const context = this, args = arguments

    const later = () => {

Eslint warnings are like the warnings mentioned above, they are there for a reason. They were written by people who are top level experts in this field, they are there to help you be a better dev, and there to stop you writing buggy code.

If you use es-lint disable, you must provide:

    // Explain: reason for using, why you think eslint is wrong
    // Blame: Your Name Here

I’ve only ever found two or three places where eslint disable was the right thing to do. It's rare.

Instead of using disable - google the problem, then fix your code. If you can’t fix it so the warning goes away, contact one of the more senior guys, then work it out together.

If you think the eslint configuartion is wrong, talk to your team lead and change the configuration to reflect your reasoning.

Use $forceUpdate

99% of the time $forceUpdate() is not the correct solution, you can achieve the same results using :key and $set(), and sometimes $nextTick().

There is almost never a reason to reload an entire component tree.

If you find your self in a position in which you realy want to use it, contact me or one of the senior guys to work out a way to get around the problem. $forceUpdate() can easily trigger a full page reload, which is super bad for user experience, and makes a Single Page Application behave the same way a standard HTML SSR app would behave. Not good - and can always be fixed using other Vue API methods.

Include Magic Numbers and String Literals

Bad

const foo = 300000
this.bar = 'some awesome string'

Good

import { AWESOME_CONST } from '../constants/time.js'

const FIVE_MINUTES = 1 * 1000 * 60 * 60 // Five minutes in miliseconds
this.bar = AWESOME_CONST

Pretty simple: There shouldn’t be any numbers floating around the code base, declare a variable with a descriptive name and explanatory comment, same for strings, literals can’t be internationalised at a later date and magic numbers are hard to understand if you did not write them.

Using unnecessary `<template>` blocks

Bad

<template v-if="someThing">
  <template v-if="someOtherThing && anotherThing || somethingElse">
    <div>
      // some content here
    </div>
  </template>
<template>

Templates are invisible elements provided by VueJs to allow for grouping elements together. You dont need a template to use v-if or v-show. You can use v-if and v-show on any element!

Also Bad

<template v-if="something">
  <cool-component
    v-for="(datas, index) in arrayOfData"
    :key="index"
  ></cool-component>
</template>

Using a template because you can’t use v-if and v-for on the same element. Much easier to use a computed property and Array.filter() or Object.keys()

<cool-component
  v-for="(datas, index) in filteredArrayOfData"
  :key="index"
></cool-component>

computed: {
  filteredArrayOfData() {
    return arrayOfData.filter(value => {
      return value !== something
    })
  }
}

It will perform faster, it's easier to read and you are using the Vue API correctly.

There is really only one place where you should be using a <template> when you want to group a number of elements together for conditional visibility.

<template v-if="something">
  <div>{{ someOtherData }}</div>
  <cooler-component></cooler-component>
  <span>{{ fooBar }}</span>
</template>

Use `!important` when we don’t need to

Anytime you find you self using !important you are probably in the wrong. When you find your self in a position in which you feel like you have to use the !important rule, it is generally because the structure of the CSS/SCSS files in your code base is incorrect. The biggest thing to remember is that CSS built as a hieracy, the reason you have to use !important is either because someone else used it before you (which leads to a never ending battle in CSS of over ridding rules using !important) or, because third party vendor CSS files have been included too far down in the CSS hieracy.

I admit that some times you will have to use !important - but - before you use it, take a moment and ask your self why you are having to use it.

It's much better to fix the problem than avoid it. If you look at the CSS rules in the browser developer console, can you see if you’re over ridding a rule from a Vendor css file, or a rule that we wrote. If it’s a Vendor rule, then look at where it's being imported, is it in main.js? If it is, is it imported before, or after the file you are currently working on?

If you can’t work out why your having to use !important get in touch with Hamish and get some help, it's usually pretty easy to fix.

Using a library when you could just write the code yourself

Currently, one of our biggest problems I see is bundle size. I've seen codebases downloading 10 MB of assets on load, which is slow to begin with, but those assets still need to be parsed and read into memory by the browser. This makes apps feel slow and that means users are less likely to use your product.

The main cause of our bundle size problems is too many libraries. This is very important, we need to stop using additional libraries to solve problems we could easily solve by writing code. After all, we are developers to right?

In some cases, a library is the right option, but in a lot of cases it isn’t. I've seen some hilarious examples of this, and have started to write a post on this specifically, enough said for now.

Using `eval()`

Read the MDN docs, they have a good entry on this. Basically, it's a well known security risk, and should never really need to be used. You can just about always replace eval() with window.Function().

Forgetting to commit the package-lock.json

Always commit the package-lock.json. It's how we ensure that everyone on the team is running the same versions of packages in their node_modules folder. Basically, the package-lock.json builds a list of the dependencies of the packages in your package.json, in our code bases it can be thousands of packages. If one team member is running v0.12 and another team member is running v1.01 it can lead to some one saying…

How come your local works and mine doesn’t?

These problems can be really hard to debug, and it's easy to prevent!

DEV Community: Hamish Clulee

One Build System - Multiple Vue Apps - Shared Components

How to achieve this and how to maintain developer experience while doing so.

The What And The Why

Things I Tried On The Road To Completion

The Solution

The Result

The Drawbacks

Wildcard subdomains on digitalocean using Express and Nginx with Let's Encrypt for SSL.

The Why and The What

DNS

SSL using Let's Encrypt

Nginx

CORS

Conclusion

Tips For New VueJs Players

Not using the same name for component file, component template declarations and a components name property

Not line wrapping

Not using the same NodeJ version between code bases

Not providing a :key when using v-for

Not writing reusable unit's of code or new components

Some examples

Ignoring warnings from build system, eslint, or VSCode

Using eslint-disable

Use $forceUpdate

Include Magic Numbers and String Literals

Using unnecessary <template> blocks

Use !important when we don’t need to

Using a library when you could just write the code yourself

Using eval()

Forgetting to commit the package-lock.json

Using unnecessary `<template>` blocks

Use `!important` when we don’t need to

Using `eval()`