Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error: Cannot find module 'image'. Running Laravel on localhost. #21

Open
nazrinnoorzan opened this issue Jul 7, 2021 · 9 comments
Open

Comments

@nazrinnoorzan
Copy link

Is this can only be used with Vapor?

I've setup a local Laravel and follow your code implementation example, and I don't have any error when running the command php artisan sidecar:deploy --activate

But on the /ogimage, I got error saying -
Lambda Execution Exception for App\Sidecar\OgImage: "Error: Cannot find module 'image' Require stack: - /var/runtime/UserFunction.js - /var/runtime/index.js. [TRACE] Runtime.ImportModuleError: Error: Cannot find module 'image' Require stack: - /var/runtime/UserFunction.js".

@nazrinnoorzan
Copy link
Author

image

Owh yeah, and I noticed why the folder and file name here inside the Lambda is difference? Why it becomes __resources/lambda_image.js ? And even I test execute directly from here also fail.

@aarondfrancis
Copy link
Contributor

That's odd, I wouldn't expect to see __resources. Can you share what your PHP class looks like?

@aarondfrancis
Copy link
Contributor

Is this can only be used with Vapor?

Also no, you should be able to run it from localhost just fine!

@nazrinnoorzan
Copy link
Author

nazrinnoorzan commented Jul 8, 2021

That's odd, I wouldn't expect to see __resources. Can you share what your PHP class looks like?

app/Sidecar/OgImage.php

<?php

namespace App\Sidecar;

use Hammerstone\Sidecar\LambdaFunction;

class OgImage extends LambdaFunction
{
    public function handler()
    {
        // Define your handler function.
        // (Javascript file + export name.)
        return 'resources/lambda/image.handler';
    }
    public function package()
    {
        // All files and folders needed for the function.
        return [
            'resources/lambda',
        ];
    }
}

resources/lambda/image.js

// const { createCanvas } = require("canvas");
exports.handler = async function (event) {
    console.log(event);
    // const canvas = createCanvas(1200, 630);
    // const context = canvas.getContext("2d");
    // context.font = "bold 70pt Helvetica";
    // context.textAlign = "center";
    // context.fillStyle = "#3574d4";
    // // Read the text out of the event passed in from PHP.
    // context.fillText(event.text, 600, 170);
    // // Return an image.
    // return canvas.toDataURL("image/jpeg");
};

routes/web.php

<?php

use Illuminate\Support\Facades\Route;
use App\Sidecar\OgImage;

Route::get('/', function () {
    return view('welcome');
});

Route::middleware(['auth:sanctum', 'verified'])->get('/dashboard', function () {
    return view('dashboard');
})->name('dashboard');

Route::get('/ogimage', function () {
    return OgImage::execute([
        'title' => 'Executing Functions',
        'url' => 'https://hammerstone.dev/sidecar/docs/main/functions/executing',
        'template' => 'docs/sidecar'
    ]);
});

@aarondfrancis
Copy link
Contributor

image

That's quite strange. I ran it locally and am seeing the expected folder structure.

Are you running this from a Windows machine? I might have to check on that if so

@nazrinnoorzan
Copy link
Author

@aarondfrancis

Yup, on Windows 10.
For now my work around is edit back the handler function to the correct path created inside the Lambda, in this case return './__resources/lambda/image.handler';

I'll check on my 2nd Windows PC also to see this is happening or not.

@aarondfrancis
Copy link
Contributor

@nazrinnoorzan thanks for the report. I'll try to add a Windows machine to the GitHub actions build so I can test it there. I don't really understand where that would be coming from. It looks like it's also removing the lambda folder and renaming your file lambda_image.js for some reason.

@wilsenhc
Copy link
Contributor

wilsenhc commented Feb 18, 2022

I have this same problem on Windows 11.

Isolated the problem to the Hammerstone\Sidecar\Package class.
Paths have an extra \\ at the beginning after removing the base path.

@w00key
Copy link
Contributor

w00key commented May 6, 2022

As @wilsenhc said the problem is in Hammerstone\Sidecar\Package class, looks to specifically be

prependBasePath() which uses DIRECTORY_SEPARATOR which resolves to \ on windows which affects the path written into the zip. Replacing with '/' instead of DIRECTORY_SEPARATOR fixes the issue. Other platforms should already be resolving to /

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants