I've been trying to understand how to setup systems from
the ground up on Ubuntu. I just installed redis
onto
the box and here's how I did it and some things to look
out for.
To install:
When the directory structure of your Node.js application (not library!) has some depth, you end up with a lot of annoying relative paths in your require calls like:
const Article = require('../../../../app/models/article');
Those suck for maintenance and they're ugly.
Here's how you validate a mailgun webhook in Node.js (as per the mailgun docs for securing webhooks)
'use strict';
var scmp = require('scmp')
, crypto = require('crypto')
. mailgunPrivateKey = 'XXXXXXXXXXXXX'
, mailgunTokens = {}
, mailgunExpirey = 15 * 60 * 1000
const EXTENSION_TYPE = { | |
0x01: 'PlainText', | |
0xF9: 'GraphicControl', | |
0xFE: 'Comment', | |
0xFF: 'Application' | |
}; | |
/** | |
* Returns total length of data blocks sequence | |
* |
Hey everyone - this is not just a one off thing, there are likely to be many other modules in your dependency trees that are now a burden to their authors. I didn't create this code for altruistic motivations, I created it for fun. I was learning, and learning is fun. I gave it away because it was easy to do so, and because sharing helps learning too. I think most of the small modules on npm were created for reasons like this. However, that was a long time ago. I've since moved on from this module and moved on from that thing too and in the process of moving on from that as well. I've written way better modules than this, the internet just hasn't fully caught up.
@broros
otherwise why would he hand over a popular package to a stranger?
If it's not fun anymore, you get literally nothing from maintaining a popular package.
One time, I was working as a dishwasher in a restu
This is an example of how to ignore a global validation pipe for a specific parameter, e.g. a request body. In fact, this example just shows a request body but you could apply this principle to other decorators.
This approach assumes validateCustomDecorators: false
in the global validation pipe. If validateCustomDecorators
is true in the global pipe I think you're out of luck. If that is your situation, consider refactoring so that validateCustomDecorators
is false in the global pipe and then have each custom decorator add validation if it needs it.
The NestJS ValidationPipe
does not validate custom decorators. So, in this above example we just make a @RawBody()
param decorator, and NestJS will skip validating it.