error with esm on windows

[fastify]

error with esm on windows

[mcollina]

Unfortunately I do not know how to fix this. I'm moving this to fastify-autoload as a bug.

I might need some help from a Windows users here.. maybe @StarpTech or @Ethan-Arrowood?

[StarpTech]

Because in Linux a path is a valid file URL? 🤔

[mcollina]

@StarpTech can you open an issue on node core on this and tag me on it? Thanks. This is very confusing.

[mcollina]

I have to admit I have not tested that setup on Windows.
Can you please console.log(join(import.meta.url, 'routes'))?

[amis-shokoohi]

C:\Users\amis\Desktop\fastify3-test\routes

[Eomm]

The join from desm is doing this work?

import { dirname } from 'path';
import { fileURLToPath } from 'url';

const __dirname = dirname(fileURLToPath(import.meta.url)); ... path.join(__dirname, 'public'))) ...

[mcollina]

yes, that's the idea

[amis-shokoohi]

I've actually tried that but still getting the same error.
I also went through fastify-autoload/index.js in debug mode, it seemed to work properly.
The problem is with esm. I rewrote it with cjs, it worked. I was just too excited to use esm.

[fox1t]

This seems the same as this one nodejs/node#31710
Isn't this by design?
From what I am understanding we need to do the opposite of fileURLToPath (since in ESM context the absolute paths need to start with file://), so we need to use pathToFileURL.

[StarpTech]

How can I help? Will pathToFileURL solve the issue?

[fox1t]

@StarpTech my bad, I am making some test now and import.meta.url indeed has already file://.

[fox1t]

@StarpTech if you are a windows user just try to reproduce the issue using the provided apps.mjs and /routes/hello.js
It would be nice to know that is the file value at 117 line on windows.

[StarpTech]

console.log(join(import.meta.url, 'routes')); = "D:\repositories\fastify-autoload\route"

It would be nice to know that is the file value at 117 line on windows.v

D:\repositories\fastify-autoload\routes\hello.mjs

I could fix it with

fastify-autoloader/index.js

  if (type === 'module') {
    content = await import(url.pathToFileURL(file).href)
  } else {
    content = require(file)
  }

app.js

export function dirname(importMeta) {
    return path.dirname(filename(importMeta));
}

export function filename(importMeta) {
    return url.fileURLToPath(importMeta.url);
}

export default function (opts) {
    const app = fastify(opts)

    app.register(autoload, {
        dir: path.join(dirname(import.meta), 'routes')
    })


    return app
}

[fox1t]

Nice, as supposed it worked! Now it would be nice to know why it was missing in the first place. Any clouds @mcollina ?

[fox1t]

I think that since fastify-plugin handles ESM natively the users doesn't have to use desm package. 🤔

[amis-shokoohi]

Oh thanks
So passing C:\...\hello.js to import() rather than file://C:/.../hello.js was the problem?

[mcollina]

Nice, as supposed it worked! Now it would be nice to know why it was missing in the first place. Any clouds @mcollina ?

No idea. The above code is exactly doing what desm is doing. See

https://github.com/mcollina/desm/blob/master/index.js

[amis-shokoohi]

Can I steal @StarpTech code and send a PR? 😄

[mcollina]

sure. I don't 100% understand the problem, but +1

[StarpTech]

@amis-shokoohi feel free 😄

[StarpTech]

@mcollina the issue sits not there. We need to pass file URL to await import(), C:\ isn't one.

[mcollina]

why the heck this works on Mac and Linux then? :)

[mcollina]

Released as v3.0.8!

[StarpTech]

Indeed, I tried it with WSL2 on Windows and /mnt/d/repositories/fastify-autoload/routes/hello.mjs is a valid file URL 😄 feels like a bug to me in Node.js. It's odd that the API doesn't abstract that behavior.

[fox1t]

The Node.js parser takes c: part of the Windows paths as protocol. :/