TypeScript clarification

[jhechtf]

Tl;DR: Can't get the autoPrefix thing to work with TS files & ts-node.

I've tried to use autoPrefix two ways with TypeScript files, and I cannot seem to find a way to it to work as expected.

Things I've tried

First Attempt

I tried to add the options.prefix to the Autoload call, like so

// server.ts
import * as Fastify from 'fastify';
import * as Autload from 'autoload';
import { join } from 'path';

const fastify = Fastify();
fastify.register(Autoload, {
  dir: join(process.cwd(), 'services'),
  includeTypeScript: true,
  options: {
    prefix: '/api'
  }
}

fastify.listen(3000, '0.0.0.0', (err, address)=> {
  if(err) {
    console.error(err);
    process.exit();
  }
  console.log(`Listening on ${address}`);
})

// services/user.ts
module.exports = (fastify, opts, next)=>{
  fastify.get('/user', (req, reply)=> { reply.send('hi'); });
  next();
}

This only adds in the /user route, and not /api/user

Second Attempt

Basically the same server.ts setup, minus the options object.

// services/user.ts
module.exports = (fastify, opts, next) => {
  fastify.get('/user', (r, reply)=>{reply.send('hi'); })
  next();
}

module.exports.autoPrefix = '/api';

In both cases /api/user is not found, but /user is.

Any tips on how to fix this? I'd be happy to submit a pull request for the documentation once I have a solution.

[mcollina]

I think there might be a bug in the code! Would you like to send a fix?

[jhechtf]

I can look into it, but if you know what it is it may just be faster for you to. I hadn't looked too hard into the code, I just figured maybe I was screwing up somewhere

[jhechtf]

In fiddling around some more it seems to actually be an issue with how fastify-plugin interacts with fastify-autoload. I'll look into it some more as it may be worth noting this for any TypeScript users, but if it is the case then it's likely not any fault of autload

[mcollina]

autoPrefix works in JavaScript here, so it's likely a bug in the typescript integration.

[jhechtf]

the issue seems to come down to the fastify-plugin module. It modifies imported objects in a way that seems sort of odd let me see if I can hop a screenshot.

Edit Gonna try something. will let you know if it works or not. If it does I'll

[jhechtf]

Working

the first line is for a TS file that is wrapping the exported function in fp() from fastify-plugin (in the real-use scenario, I need to use the fastify-plugin plugin because I need access to the decorators added on in other files). The second line is a route that works as it is displayed, but will not work if I wrap it in fp() as the object has the same sort of decorator information presented. See the screenshot below.

Not Working

This will no longer work -- if compatibility with the fastify-plugin module is expected of this, then this is an issue. If it is not expected, then this is an odd bug, but you are able to get past it if you only use the fastify-plugin module only for things that need to be available in other plugins, and not for web-direct things (i.e. splitting out things like db instances into files that use that the fp() wrapper and using just a raw export for anything that defines a web route).

[jhechtf]

@mcollina not sure if you saw my other comments.

[mcollina]

Compatibility with fastify-plugin is expected. It works in Javascript, so it should work on TS as well.

[jhechtf]

Alright, I'll look into what can be done to resolve the issue -- might take me a bit since I'm swamped with my 9-5 right now, and I'm going to have to look into fastify-plugin to determine what's going on from that end.

[jhechtf]

Random Update:

This appears to be a problem not only with TypeScript, but with autoloads interactions with fastify-plugin in general. I was trying to build a quick example application that had some plugins and services, and I found that I could not access a route that I had wrapped in fastify-plugin out of habit. Removing the fastify-plugin wrapper makes the expected route work.

Doesn't Work
when checking localhost:3000/api/users => "nothing found"

// services/users.js
const fp = require('fastify-plugin');
const AsyncFn = require('./asyncFn');

module.exports = fp((fastify, opts, next) => {
    fastify.get('/', async ()=>{
        return await AsyncFn();
    });
});
module.exports.autoPrefix = '/api/users'

Works
when checking localhost:3000/api/users => expected results.

// services/users.js

const AsyncFn = require('./asyncFn');

module.exports = (fastify, opts, next) => {
    fastify.get('/', async ()=>{
        return await AsyncFn();
    });
};
module.exports.autoPrefix = '/api/users';

[mcollina]

That looks like a bug! Would you like to send a PR to fix it?

[jhechtf]

I'll try to. Looking into how it all works together to determine if it's something that should be fixed on fastify plugin's side or autoload's side.

[jhechtf]

After some fiddling I'm left with a question: What exactly does the Symbol.for('skip-override') part do? It seems to be that is the cause of the issue with routes not listening to the prefix, though I'm fuzzy as to why. If I take a service that currently does work with the autoPrefix, and add module.exports[Symbol.for('skip-override')] = true it fails just as though I was using fastify-plugin.

I've read the only available doc that I could find (https://github.com/fastify/fastify/blob/master/docs/Plugins.md) but it doesn't really do a whole lot in-depth.

[mcollina]

That’s exactly the use that fastify-plugin provides. It’s _built_ for that. Il giorno lun 26 ago 2019 alle 18:53 Jim Burbridge <notifications@github.com> ha scritto:

…

After some fiddling I'm left with a question: What exactly does the Symbol.for('skip-override') part do? It seems to be that is the cause of the issue with routes not listening to the prefix, though I'm fuzzy as to *why*. If I take a service that currently does work with the autoPrefix, and add module.exports[Symbol.for('skip-override')] = true it fails just as though I was using fastify-plugin. I've read the only available doc that I could find ( https://github.com/fastify/fastify/blob/master/docs/Plugins.md) but it doesn't really do a whole lot in-depth. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#44?email_source=notifications&email_token=AAAMXY73H2C6LG6NBXAYPWDQGQC7PA5CNFSM4IHN3IGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5E6VJA#issuecomment-524937892>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAMXY2ERDA4DH6QNZUYYHTQGQC7PANCNFSM4IHN3IGA> .

[jhechtf]

I honestly can't see anything in the fastify-autoload code that would be causing that, so this bug might lead me down into the regular fastify repo. I'm at work now, so I'll check after I'm done for the day.

[jhechtf]

I decided to test my hypothesis by creating a quick example that did not use fastify autoload or plugin but did use the Symbol.for('skip-override').

The results are the same -- a plugin called with the skip-override set to true ignores it's passed prefix, and a plugin registered without it does not. I'm assuming this bug is therefore an issue with the fastify base itself, and not with fastify-autoload so I'll be closing this issue.

[mcollina]

@jhechtf it's not a bug, it's how fastify works. It's documented in https://www.fastify.io/docs/latest/Plugins/#route-prefixing-option.

[mrob11]

@jhechtf I just started running into this problem today in a new project. Did you ever get around this?

[diego-betto]

@jhechtf it's not a bug, it's how fastify works. It's documented in https://www.fastify.io/docs/latest/Plugins/#route-prefixing-option.

Now we get 404 there