DEV Community: Marcel Cremer

How to create a scalable vue.js setup (Part I)

Marcel Cremer — Mon, 18 Jan 2021 07:00:25 +0000

If you know me a little bit or read my bio in social media, you'll probably have noticed that I'm a big fan of vue.js (and if you don't follow me right now, consider following me on twitter 😜).

This is for a reason: Coming from angular, I personally like the approaches they chose to organize and do things. They have dependency injection, routers, stores, a test harness and much more. However, it has also a big downside: Everything feels a bit big and bloaty and I always had the feeling, that I could not develop as fast in angular as I should.

Introducing my vue.js setup

If you don't know vue.js, you can check it out here. Vue.js is a rather small framework (20KB compressed and minified) that focuses on the "view" part of the application (that's why it's pronounced /vjuː/, like "view" - just in case you wondered). Additionally, there are plenty of resources, plugins and so on that you can use to customize it to your needs (a comprehensive list is available here: awesome-vue). So let's start:

The Foundation: Vue-cli

Comparable to angular, the vue environment also has a cli that you can use to generate an application according to your needs. Even better, you can choose what tools you like to use and you can configure it to your needs (e.g. webpack) without ejecting the configuration. A simple command

vue create <projectname>

creates a new project and you are able to choose, which css-framework you like to use, if you want babel and / or typescript, if you create a PWA (automatic manifest generation), which test framework for unit and e2e tests you prefer and if you opt for eslint or the deprecated (but still awesome) tslint. This alone is a huge advantage, as you are able to create the environment in a way that perfectly matches your needs. I personally use the configuration

[Vue 2] dart-sass, babel, typescript, pwa, router, vuex, unit-jest, e2e-cypress

but this can be very opinionated. After creating the project, you can launch a pretty cool dashboard via

vue ui

which shows you not only your projects (it's possible to have a multi-project Monorepo in vue), but also the bundle sizes and the transpilation statistics. It's awesome!

Getting stuff: Dependency injection

As mentioned before, vue only concentrates on the view part of your application. So the next thing I usually tend to do is to introduce dependency injection and for this task, I absolutely love inversify.js although people are discussing on how to proceed with future maintenance. It's very well established and plenty of larger projects are using this, so that I'm optimistic that even if the maintainer does not support it in the future, there will be forks or other ideas to further support this framework.

After installation, I basically do the whole DI configuration in three files:

di.types.ts

export const TYPES = {
  /**
   * Services
   */
  DATA_SERVICE: Symbol.for('DATA_SERVICE'),
}

This file defines Symbols, so that inversify has unique tokens to inject things.

di.container.ts

import { Container } from 'inversify';
import getDecorators from 'inversify-inject-decorators';

export const container = new Container({ defaultScope: 'Singleton' });

const { lazyInject } = getDecorators(container);
export default lazyInject;

This file is just to create a singleton container and make it possible to "lazy inject things". This is necessary due to a babel / webpack issue: On startup of the application, several files can request stuff and if you don't have the container imported from an own module, some things like lazy inject won't work

di.config.ts

import 'reflect-metadata';
import { container } from '@/di.container';
import { TYPES } from '@/di.types';
import { DataService } from @/services/data.service.ts;

container.bind<DataService>(TYPES.DATA_SERVICE).to(DataService);

Here we bind a service to our previously defined Symbols. That's basically the whole magic about itroducing dependency injection. Easy, wasn't it?

Property decorators

The next thing to tackle for a scalable application is, that we want to have a well written component that is easy to read and to reuse. Vue components are usually single file, which has it's benefits (e.g. if you want to change some css, and then html and oh, you also need to introduce this property in typescript...). It's also easier to maintain some code standard about how large a component should possibly become, if you had single file components (e.g. >250loc => linter error). To additionally increase readability, I like to use typescript class components flavoured with vue property decorators.

Here's some example, how a class component with decorators and dependency injection could look like:

<template>
    <div class="hello-world">
        {{ message }}
        The sum of {{ a }} + {{ b }} is {{ sum }}.
        Our current mood is {{ mood }}
    </div>
</template>

<script lang="ts">
    import lazyInject from '@/di.decorator';
    import { TYPES } from '@/di.types';
    import { Component, Prop, Vue } from 'vue-property-decorator';

    @Component
    export default class HelloWorld extends Vue {
        mood!: string;

        @lazyInject(TYPES.DATA_SERVICE) 
        dataService!: DataService;

        @Prop()
        message!: string;

        @Prop()
        a!: number;

        @Prop()
        b!: number;

        get sum() {
            return a + b;
        }

        async mounted() {
            this.mood = dataService.get(`/api/v1/mood`);
        }
    }
</script>

<style lang="scss" scoped>
.hello-world {
    color: blue;
}
</style>

pretty neat, isn't it? 😁 Having this result is a good first step for creating a scalable vue app. If you are interested in more of this topic, I'm gonna talk about state management, testability and deployment (e.g. different environments) in the next part of this article series. Thank you for reading!

5 reasons you might NOT need a mobile app

Marcel Cremer — Tue, 10 Nov 2020 07:38:10 +0000

When I'm scrolling through my mobile phone the last days, I'm recognizing that I haven't installed many apps that were not pre-installed. To be honest, for a long time was thinking, it was just me with this "app avoidance behaviour". However, I went curious and asked my social bubble about how many and what apps they have installed. After I got some input, I started to realize, that others also don't download many apps for different reasons. In fact, sometimes it feels even painful to only have the "tool" app, without a suitable Desktop or web alternative (e.g. for my bank accounting analytics). So today, whenever I have to argument about pro / con app, I have 5 indicators when you don't need an app:

1. You have a business2business model

Let's start with something simple: If your business is B2B, your main application shouldn't be an app. The reason is simple: B2B licensing is almost never done via the app stores or in-app transactions. What happens instead is, that people will download your app, won't be able to use it and leave bad reviews in the app store (no matter HOW FAT YOU WROTE, that it's not for public usage 😜). This will cost time, money and nerves. So if you publish something in an app store, make sure it provides some value for B2C (business to consumer).

2. You don't need too much "native" features

Now this is a big one for me: Why do you actually NEED a mobile app? Does it have any benefit to implement it, or is it just "cool" to have an app? Many apps that are offered are not using the full potential of native apps. If you don't need to have access to all the 28 sensors of the latest x-phone and don't need the store as marketing instrument, why should you take the extra effort to maintain a native app? Even if you need some "native" features, you can most often rely on using a progressive web app (PWA), because things like camera, push messages etc. are already supported. If you're curious, open this page on your mobile phone and you can see the exact featureset, that is provided without creating a native app.

3. You have a data heavy application

As I wrote in the introduction, some apps can be a pain to use. This might be personal taste, but I can identify them for myself most of the time as "data heavy applications". What do I mean with that? Every app, where you need to type much, swipe much, present analytics, show plenty of tables and so on. Smartphones don't have a physical keyboard (anymore) and most people cannot write 1 sentence correctly without looking at the screen. It might be okay to write some sentences in a messenger or a short email on the mobile, but don't expect the user to write novels in your app. And if you really need to provide this app, please provide at least a desktop / web alternative, so that they have the choice to do the heavy work on a computer.

4. Your development cycle becomes more complex and expensive

Providing apps is expensive. And I don't mean, it creates "a bit" additional expenses - it's huge!

Let's start with the obvious things:

You have to have a developer account per app store (at least google and apple)
You pay for the publishing into the appstore
You need a different build pipeline to deploy into the stores

So that's what everyone has on their mind, if they think of additional costs, right?

Now let's think a little bit further:

Your developers need to get a huge knowledge about all platforms

I hear you saying: "Why? There's react native, nativescript and whatever out there! Writing native apps is easy!"

Nope, it's not!

First of all, those abstraction Frameworks are exactly this - an abstraction of the different platforms with the benefit of a "single codebase". However, abstraction always means, that it has to find the lowest common denominator between the different platforms. So as long as you don't do something "special", your code will work out of the box. But as we identified in the previous reasons already, the whole point about providing an app, is to provide something special!

So faster than you even know it, your developers have to learn at least three frameworks: Android, iOS and react native / nativescript / ...

Most of the time, the abstraction frameworks also have some "CSS-like" styling syntax. This basically means, that you cannot use your already created CSS from your web application, but have to write the exact same code in a different manner to make it app compatible.

Apple has built their own community

Have you ever tried to develop an iOS app with Windows? It doesn't work, because apple has shut down all doors to the outside. If you want to have an iOS app, you're forced to give out macs to your developers (and if they aren't used to it, they'll wonder about the new keyboard layout😁).

"But we're already using macs to work!"

Okay cool - this simplifies things. But... how do you test iOS apps in your continuous integration pipeline?

The answer is: You need additional services, that offer you dedicated time on a mac to do automatic testing. This is (of course) expensive, because there are not many providers who offer calculation power on macs.

5. You have a flexible application with lots of changes

Another thing that isn't considered when introducing an app is, that it takes time to update it in the app store.

Have this breaking change of the API or this super critical security update? You have to wait up to 48 hours until it's out there!

The different platforms use a combination of manual and automatic reviewing which is of course good for the app store reputations, but very bad for the developer experience. And depending on the platform, you cannot even force the update of your app, so people might still be working with an old version.

Summary

As you can see in my argumenation, the decision of making an app should be well reasoned. I'm not all against providing native apps for your customer, but I think the decision in favor for an app is oftenly made way too quickly and without considering, how much impact this will have on your product lifecycle and maintenance costs.

Explain like I'm five: How does docker application update work?

Marcel Cremer — Wed, 29 May 2019 06:10:43 +0000

Whenever I read about docker or containers in general, I wonder how it could possibly work in real world applications.

That's what I (think I) understood until now:

docker encapsulates an application, but not the applications data
updates are done by completely exchanging the applications container (e.g. remove myApp 1.0.0 and start myApp 1.0.1)
all non-volatile data is stored outside of the container in volumes (which are basically shared directories between the host and docker's containers)

However, if that's how it's done, how do Update processes / database schema updates / ... work?

A more specific example: If I have an postgres container and I need to update the database version (ergo: install the new container). How do I update the database files to the newer version, when the postgresql installation / updater will be never executed?

🏇 A simple tip to improve angulars compilation speed

Marcel Cremer — Fri, 17 May 2019 06:09:15 +0000

Do you have a large angular application that takes too long to compile / serve / compile tests? This little thing helped me:

Increasing the node process memory

By default, a node process can take up to 1,76GB of RAM. This is by original design of Javascript, where the assumption was, that a single thread (which node has) will not exceed a total of 2GB RAM.

However, things got a bit more complex the last few years, because JavaScript frameworks evolved and allowed to compose different libraries to a framework or in our case - the angular compile mechanism.

And if your compilation process reaches this limit, the node garbage collector will start alternating with the compilation process, freeing up just enough space so that the next piece of work can be executed by ngc.

If you're like me, you might think: Why the hell should ngc ever exceed this limit?!?

The short answer is: Because it does many things for you 😃

Okay, to be a bit more specific:

it bundles assets into your final build
it keeps several hundred files in memory to do tree-shaking
it compiles scss-files
it organizes chunks into module / vendor chunks
it seperates often used code pieces for shared use into a common chunk
...and much much more :)

So how do we get rid of that "free memory / do a bit more work / free memory"-cycle?

Increasing the node memory limit with max_old_space_size

Node has a simple flag to change the maximum RAM consumption before the garbage collector will start to agressively free up memory. You can use it like

node --max_old_space_size=size in MB

As I have 24GB of RAM in my machine, I don't have any problem to assign 8 GB to the node process. But I also don't want to lose the comfort of the ng cli, so how to automatically assign the parameter to ng commands?

The solution is simple, but maybe not too obvious:

We call the ng cli directly out of the node_modules folder using a node script. I called this variant "nghm" (for ng high memory) and built it like this:

"nghm": "node --max_old_space_size=8096 ./node_modules/@angular/cli/bin/ng"

Having this script in mind, we can transform "ng serve" into

npm run nghm -- serve

which will now consume up to 8GB RAM. A production build could look like

npm run nghm -- build --prod --progress=false --aot=true --vendor-chunk

And the Numbers?

Well, that might depend from project to project, but in my project this particular change has reduced the compilation time from ~3:26min to ~1:36min (I picked 2 times from our CI system, that are pretty average - no science here😉).

It might be influenced by how large your assets are, how many files are compiled and so on, but if you struggle with long compilation times, just give it a try.

Originally published at marcel-cremer.de

Why your Open Source Project might lack (my?) contribution (1)

Marcel Cremer — Thu, 16 May 2019 06:09:32 +0000

Many developers like to "give something back" to the community by supporting Open Source projects in one way or another. The types of contribution can vary widely, e.g.:

Reporting Issues and / or Feature Requests
Fixing things, they need themselves
Add some value (a new Feature, better documentation, ...)
"Swarm intelligence" by contributing to brainstormings or discussions
Testing (and giving feedback)

However, sometimes contributors are also repelled by various reasons. The following reasons are some of mine...

How important it is, to have a low hurdle in your project

My first and top reason not to contribute to a project is...

...not finding a good starting point!

Like really, if you check out a project, maybe install dependencies and then the build doesn't work first try, there's a chance of about 90% percent for me to drop the idea of contribution.

Sometimes it takes dozens of steps to get the build running. Sometimes you find an issue where someone reports, that step xy is missing in the documentation and it's still not updated. Sometimes you need to cherry-pick ideas from different places to get something working.

Why should I spend my time and diligence in contributing to something, that seems not important to the maintainer?

Make it easy for contributors to take the first steps, document it well and keep it updated all the time. It's really important to support people, who want to support your project!

A good example for a low first run hurdle (node-based in this case):

Check out the project
npm i
copy conf.json* to conf.json and change database setttings (json exists and just needs to be modified - easy!)
npm run serve
Success!

Now it's possible to play around with code while reading it, get instant feedback on what changes do and so on.

Keep also the following things in mind:

If you have unit tests (and I hope you have some), make them available as simple as the first compilation (e.g. npm run test:watch in this case)
if you have a database dependency, put the schema and initial seed in your VCS. No one wants to open an administration, execute ten random SQL files and maybe get a consistent database (or not)! Provide an automated script or create the database automatically on startup, if it doesn't exist!

Keep your project fast!

"Okay, so I got this library and it has a bug. I found the line of code in github already, so let's fix this real quick and send out a pull request:
git clone xyz
install dependencies...
...
...
Okay, that took a while. Let's start the program to see, if I can reproduce the error.
...
...
...
Ehm, will this ever finish?
...

If you want contributors to send Pull / Merge requests, care for your project's performance.

Sometimes the issue is obvious: Even from reading the code on the source code repository, you can put your finger on the line where the error happens.

However, to get a pull request, the contributor needs to

check out the code
install deps
maybe add a database / server / whatever
get it running
reproduce the error (or write a test)
fix the error
push it
create an issue
create a PR referencing the issue

If you ever see it from this perspective, you surely recognize that there's a lot of stuff to do (to fix your "little" mistake).

If it takes about an hour to setup the development environment, have the first compilation done and get tests running, I tend to just drop the idea to create a fix and instead just open an issue. Even if I had the patience to create this fix, I wouldn't have the time for it in my daily business.

So please keep the development cycle fast!

Some ideas to achieve this:

Create some small projects that are working for themselves instead of providing one large monolith
Keep the dependencies small
Don't create 1 million fake entries in your initial database seed. If someone want's to do stress test, he could easily apply an additional seed
Run tests on the continous integration server - especially if they aren't easy to set up locally. It'll be much easier to throw something against the server and let him validate if everything is fine, than setting up some hard-to-setup-test-suites
if you have easy to use unit tests, make sure that they have a short feedback loop. If the suite takes 3 seconds to test and someone saves every 3 seconds, 50% of the time will be wasted for compilation / waiting for tests
if it's not possible to keep the whole test suite that fast, make it easy to isolate tests. In node / jasmine for example there's an fdescribe and fit that will only execute that particular test suite / test case. Make sure, that the isolated tests are as fast as possible

Maintain your project

Everyone who puts up a project on github, gitlab or something is the so-called "maintainer", but many people don't really maintain their project.

To make this point really clear: No one expects an open source maintainer to be available 24/7 and always have an answer to any given topic.

However, if someone takes his time to carefully open an issue on your project, handle the issue itself carefully as well:

If you've seen the issue but don't have the time right now, write a short note that you've seen it and...drum roll...don't have the time to work on it right now! People like to be noticed by others, especially if they put some work in their issue. The answer

"Hey, I saw your issue but I'm on a business trip atm. Coming back 2 u in a few days"

Is already some kind of appreciation to the creator, shows that you take him seriously and also that you (and the project your maintaining) is still active.

The same is of course true for pull / merge requests. If you have 20 open requests without any notice or discussion, the 21st requests won't be opened,
because everyone will think: This project is unmaintained.

End of Part 1

Because this article seems to grow rapidly and I still have some things noted here, I'm going to make a cut at this point.

I'd love to hear, if you also struggle with some of those things and also, if you'd like to read some more on this topic :-)

Originally published on marcel-cremer.de

The Icon evolution and "How I switched from Font based Icons to SVG"

Marcel Cremer — Fri, 01 Feb 2019 07:05:46 +0000

Last week, we made the decision to migrate from our font-based icon set to feather icons - an SVG based font set. Since I've been using font based Icons like forever and had to read a bit about icons in general, I'm going to share what I learned with you. So please join me on a journey into...

The Evolution of Icon Sets

A long time ago, in a world where CSS didn't exist, Icons were displayed via images.

And it was good.
Until...

People realisied, that images are very inflexible regarding their display size. Also, they consumed much bandwidth (which was costly) and if over-used, the website became slow (at that time, each image request blocked the main thread of the browser). But luckily, CSS arrived.

So people started to use so called image sprites, where a bunch of icons were placed on one image (which was cacheable). By positioning via CSS it was possible, to extract parts of this image sprite to just show the one icon needed in that particular place.

And it was good.
Until...

Web designers had again to struggle with images. Because people wanted to have the same icon in different colors and sizes, the image sprite grew larger and larger. Also accessibility became a problem.

So at around 2012, people got a new Idea: We can have text in different colors, scale it like we want to and even apply shadows on them. We can also draw text "above" other text by CSS positioning, so we could "craft" a new character by combining 2 others. And all that, by having a small file, which contains a definition on how to draw those Characters.

But what if it didn't contain characters? What if it contained Icons?

That's how Font based Icon sets were born. The icons were drawn carefully and delivered as a font set, where each "character" represented one icon.

They could be easily accessed by writing the corresponding character (e.g. via Unicode) or later via ligatures. They could be colored and sized, combined and even CSS effects were possible on them.

Although fonts weren't made for icons, the Icon Fonts lived a long and happy life.

And it was good.
Until...

A small introduction in SVG

Scalable Vector graphics (short: SVG) are a standard to describe 2-dimensional Vector graphics in XML. According to caniuse.com, all "modern" Browsers support them. Others can be polyfilled e.g. by svg4everybody.

A simple example would be

<svg>
    <circle cx="5" cy="5" r="4" fill="currentColor" />
</svg>

which paints a circle with the current color.

Reasons to use SVG based Icon sets

Here's a (incomplete) list of benefits for SVG based Icons.

They are...

fast to paint
much smaller than traditional Image or font based icon sets
because they are basically code, they can be extended (e.g. by adding a rectangle into the above example)
consume less bandwidth, because they can be compressed for transfer (it's a text definition after all... :) )
They can even be used within a regular <img> tag (although this limits your flexibility to adjusting width and height)
while Font based Icon positioning can be tricky (because they are inserted on a pseudo element, e.g. in CSS with :before and :after selector and the content-attribute), SVG based Icons can be just placed as an element itself and will be drawn nicely in their given dimensions
SVGs support Anti-Aliasing, which makes them in general a bit sharper than their font based counterparts.

My Personal Decisions: JavaScript vs Angular implementation vs Sprites

When I started with the migration to SVG based Icons, what I first found was a JavaScript implementation that builds the SVG (first paragraph on feathericons). However, as I was working in an Angular SPA, I didn't want to use external JS and create overhead.

So my next "station" on the way to SVGs was, to check out if someone already built something for angular, and of course, someone did: Angular Feather supports the import of single icons just as needed, where needed in the angular Application. Nice!

But wait... as every icon is encapsulated in an Angular component, I wouldn't have had access to the SVG and therefor, I wouldn't have been able to modify the color of Icon parts, add additional paths to the SVG or whatever else someone could imagine.

There had to be another option, and if I carefully read the rest of the Feather Icons site until the end, I would've seen it right at the beginning: SVG Sprites!

SVG Sprites

SVG Sprites are basically an xml file, where many Icon definitions are stored with a corresponding anchor. In case of Feather Icons, the SVG sprite is about 50kb (uncompressed) which was very acceptable for my Web Application.

So I created the base class in css, which describes the overall icon behaviour:

.fi {
  width: 1em;
  height: 1em;
  stroke: currentColor;
  stroke-width: 2;
  stroke-linecap: round;
  stroke-linejoin: round;
  fill: none;
}

Because I chose relative sizes, the icons are as high as they should be in the different places according to the font size (just like their font based counterparts).

The "stroke" defines how the lines defined by the SVG should be drawn. Because it's set to "currentColor", the icon will use the current font color of it's context.

Right after defining those basics, I was able to exchange my icons to their SVG-equivalent:

<svg class="fi"><use xlink:href="/assets/feather/feather-sprite.svg#user" /></svg>

(note #user, which is the anchor reference for the Icon I want to draw out of the SVG sprite)

And what should I say? It just works!

I was even able to create additional helper classes, for small, large and 2x 3x and 4x original size, by adding a few simple CSS classes.

I hope you could also take something out of my journey through the icon evolution. Which ones do you prefer and why?

5 Tips for better NPM script organization

Marcel Cremer — Wed, 30 Jan 2019 07:16:17 +0000

Not too long ago, it was pretty normal to use grunt, gulp and other tools to organize building, testing and other tasks in JS-Projects. However, this required people to install, maintain and understand different build systems, structures and configurations.

NPM Scripts to the rescue!

Everyone who uses npm as their package manager already has a package.json and the ability, to run scripts from there. So what is more obvious, than using npm scripts for automated tasks around the project?

However, since the npm scripts is in no way opinionated about modeling complex build systems, the organisation and consistency of the scripts is in responsibility of the maintaining developer. And here are some tips on what you could do.

1. Consistent script names

If you start using NPM for several tasks, your script section might grow pretty fast. You might have for example scripts for unit testing, for integration testing, the same with coverage reports and also as watch-mode for development. If it grows organic, you might end up with something like

{
    "build": "...",
    "test": "...",
    "test-watch": "...",
    "integration-test": "...",
    "watch-integration-test": "...",
    "test-coverage": "...",
    "test-integration-coverage": "...",
    "build-prod": "..."
}

Urks...

You might not notice it in the first place, but more often you'll misspell whatever you want to do, e.g. you write

npm run integration-test-watch

instead of

npm run watch-integration-test

triggering the well known "Command not found"-Error.

So somewhen you get the idea to change it the other way around, and guess what? The next time you try it, you write it wrong again , because you don't have a system...yet :)

So what we need is some naming scheme, that is consistent in your own aesthetical point of view. For example, I use something like:

{
  "build": "...",
  "build:production": "...",
  "test": "...",
  "test:coverage": "...",
  "test:watch": "...",
  "test:integration": "...",
  "test:integration:coverage": "...",
  "test:integration:watch": "..."
}

So I start off with what I want to do, followed by specifying it or calling additional behaviours. As the order always stays the same, I'm not so likely to misspell things.

Also I have some "internal" scripts, that are only used for DRY purposes inside of the package.json. Usually I let them start with a hashtag, so that people don't get the idea to use them directly. For example:

{
  "\#:copy:assets": "...",
  "\#:copy:configuration-templates": "...",
  "\#:generate:polyfills": "..."
}

2. Performance

One thing people often don't care about is performance. If we think of unit tests, it's pretty obvious that every second counts. So if you press ctrl+s about 10 times a minute, and every testing cycle takes 3 seconds, you spend about half your time (10 * 3 = 30 seconds) waiting for your test results! Scary, isn't it?

If you're in a typescript environment, the code also needs to be compiled into javascript before the tests etc. can be executed. So take a minute upfront to think about your task execution, before wasting hours and hours with waiting.

Use modules like concurrently whenever you're able to execute tasks in parallel (e.g. having your typescript-compiler watch .ts files, and your tests watch the output .js-files).
Try to avoid that different tasks do the same (e.g. integration testing and unit testing both trigger the typescript compiler)
Make granular scripts for different tasks and chain them in convenience scripts
review your scripts from time to time to see, what bottlenecks you encounter

3. Platform independence

Because I primarily develop on windows (blame me if you want...), I really hate it when I want to contribute to some Open Source project, and the

npm run start

script fails because it's relying on some unix command. Try to use node-implementations whenever you can, to avoid platform specific code.

For Example:

Use rimraf instead of rm -rf
Use copyfiles instead of copying via OS commands
... you get the idea ;)

Even worse is the usage of npm packages that rely on native OS calls, which need to be compiled with node-gyp before being usable.

If you don't believe me, have a look at stackoverflow on how many problems node-gyp creates, before you decide to use some native OS library to "asynchronously add 2 numbers" (or other curiousities like that)!

I know, some scenarios need native libraries and that's perfectly fine, but please think twice before adding them as a dependency. If the cause is for example performance, provide a "slow, platform-indepedent, nodejs"-way as default and add the "native call"-way as a peer dependency, so people can decide themselves, if the performance is worth the native module compilation.

Always prefer options over "might not be working for someone", because the persons you otherwise push away might have sent you an incredible pull request.

4. Additional parameters

Sometimes I see projects, that have the exact same script multiple times implemented, just to add different parameters. That is fine if you're providing convenience methods (e.g. serve to start a development webserver), but if you have a dozen of them, you might also think about people just parametrizing your scripts.

So instead of

{
  "start": "node server.js",
  "start:integration-port": "node server.js --port=4202",
  "start:https": "node server.js --https=true",
  "start:integration-port:https": "node server.js --port=4202 --https"
}

you could also provide a single start command, and use -- to pass additional parameters to the script. That can be used like

npm run start
npm run start -- --port=4202
npm run start -- --https=true
npm run start -- --port=4202 --https=true

5. NPX instead of single command scripts

Since NPM 5, NPM supports a tool called "NPX". What it basically does is, it executes a script from your dependencies as node executable.

For example instead of writing

node ./node_modules/typescript/bin/tsc

you could write

npx tsc

and would execute your local typescript compiler (more information here).

Sometimes I look into projects, that have 20 NPM scripts or something, and some of them are


{
// ...
"webpack": "webpack",
"tsc": "tsc",
// ...
}

which are pretty useless. Use NPX and tighten your package.json even more.

Do you have some more tips? How do you structure your package.json?

Start. Testing. Now!

Marcel Cremer — Mon, 19 Nov 2018 07:51:54 +0000

Hello hello - nice that you got here!

If you read this, I'm pretty sure you care about your work. You want to deliver good quality Software, and of course you also want to test.

If you're like me, you really really want to test, but you just don't know to start. Like - what the...?

There are tons of testing frameworks out there, you're code looks like it could be never, ever tested at all and everytime you ask a question on the web like

"How do I test databases?"

"How can I assure, that my Rest-Service work?"

...

you get put down from the community:

"That's not Unit Testing - that's integration / end2end / ... testing! You're doing it all wrong, blah blah blah..."

But really - you don't care how it's named. I mean, you want to deliver good quality Software, so... whatever, just test it, right? It looks like there is no starting point for "normal" guys and girls out there: Either you get it, or you don't...

Wrong, wrong, wrong!

I absolutely feel you and your thoughts, because I was at the exact same point several times. When I was a total beginner at testing, I felt like:

Okay, I get this framework, but how can I apply it to my code base?
I can only test trivial and obviously working things with Unit tests (which slows me down)
The effort to test is just to high
Everytime I change my code, I also need to change my tests...
It's just not worth it!!!1eleven

Now that I'm only a relative beginner (hey, at least I dipped my toe into the water), let me tell you the dark and secret truth, no one was able to reveal to you:

Testing is not about tests. It's about Software Design!

Phew...

And here comes another one:

You're code will become better automatically, if you try to auto-test it!

Wow!

So there's really something else behind this topic, that divides beginners and pros, and now you know what. But how can someone cross this bridge?

Start testing - today!

It's that simple! You just write a test for a trivial little thing. You might even think: This won't ever go wrong, this test is useless! But it doesn't matter. Soon you'll have a hundred of them. And you'll see more and more potential for automated tests in your codebase.

Software testing is a Skill!

And every little thing you read, do and learn about it, gives you a little more experience. Not only about coding, but also about the way you design and implement your Software.

At the beginning, you might test something trivial, or you might even start with writing End 2 End tests. It doesn't matter, because every line of code will expand your horizont, little by little.

Soon you'll see, that you need to restructure your code a bit, so that you can apply a test on it.

You'll make it less coupled to external dependencies, so that you have the chance to spy/mock/stub/fake some things.
You care about Dependency injection, Dependency inversion, and about Object Oriented / Domain Driven / functional Design in General
You might write smaller chunks of codes, so that each class and method has a single responsibility (which is testable)
You might think of event or message based architectures to decouple your code even more
You start using more configuration files or parameters, so that you don't even have to code so many changes anymore
...

And most important:

You Start thinking about your code, before you write it!

It will be so awesome, because a whole new world opens up for you. You'll re-read all the stuff about design patterns, refactoring and software design and now you see so much more in it. You know how to combine things, move them around and / or reassign them with ease.

You'll feel like you're a code magician! A sort of tibetian monk with supernatural coding powers.

And someday after, it'll just become natural to think this way. You'll have it integrated in your day to day workflow. You write great code, others are stunned about, and don't even think about it.

And then, you try to help the newbies with their testing Requests on the internet...

No, this is not unit testing. You're testing with external dependencies... that's integration testing! Try to avoid overusing that... mind the upside down testing Pyramid! ... ...

Life is strange ¯\_(ツ)_/¯