sandulat / routes-gen

Framework agnostic routes typings generator. Remix ☑️ SolidStart ☑️
MIT License
281 stars 12 forks source link

Invalid driver package name or file path #19

Closed frontsideair closed 2 years ago

frontsideair commented 2 years ago

Describe the bug

I'm running routes-gen on postinstall on Github Actions, and I'm getting this error:

[ERROR] Invalid driver package name or file path.

It's running on node:16-bullseye-slim image, and it's running without any issues on my local machine. I tested it even after deleting node_modules.

The relevant parts of my scripts:

    "postinstall": "remix setup node && npm run routes-gen",
    "routes-gen": "routes-gen -d @routes-gen/remix"

and relevant devDependencies:

    "@routes-gen/remix": "^0.3.0",
    "routes-gen": "^0.4.0",

Your Example Website or App

a private repo

Steps to Reproduce the Bug or Issue

  1. Run npm install --production=false on Github Actions under Docker node:16-bullseye-slim image

Expected behavior

The driver should resolve correctly

Screenshots or Videos

No response

Platform

Additional context

No response

frontsideair commented 2 years ago

I think I got the reason this is happening. The Dockerfile runs npm install with only package.json and package-lock.json, but the routes aren't there. I moved the script from postinstall to build and it worked. So I'm guessing the error message was misleading?

sandulat commented 2 years ago

Hey @frontsideair. Not really sure about this one. Here's the way it's trying to resolve a package or a local file:

  let driver: Driver | undefined = undefined;

  try {
    driver = await import(require.resolve(cli.flags.driver!));
  } catch {}

  if (!driver) {
    try {
      driver = await import(`${process.cwd()}/${cli.flags.driver}`);
    } catch {}
  }

  if (!driver) {
    return markAsFailed("Invalid driver package name or file path.");
  }

Might be some specific incompatibility between the node API and node:16-bullseye-slim?


Also, I'm not sure why you'd put the routes-gen command in postinstall, and have it running in your CI/CD.

My guess is that the confusion of running this command during CI/CD comes from other experiences, like using Prisma. With Prisma, you run the generate command during CI/CD because the state of your DB might differ in different environments, and the generated types will differ as well.

Speaking of routes-gen, you should usually run this command when you change any of your routes only, or use the --watch flag to have it happen automatically. The generated file should go to the repo since the generated typings actually represent the real state of your routes, which are static and do not change during CI/CD, or from environment to environment.

This is the actual reason I've decided initially to not place the generated file in node_modules and make people run the command during deployments, the way Prisma does (it makes total sense for Prisma).

sandulat commented 2 years ago

@frontsideair Try moving both routes-gen packages from devDependencies to dependencies, and then run the action again.

frontsideair commented 2 years ago

Ah, sorry for the lack of context. I prefer not to commit autogenerated files to version control, as they can be generated from existing files. They contribute some noise to the commits and a contributor with a misconfigured environment can forget to commit them, which will cause drift.

I use the watch command during development but it is gitignored and I let the CI generate it. Since I moved it to build I no longer have any problems and I don't have any request for changes.

I kept the issue open was to understand the error, but I guess your my Docker config was removing devDependencies so it should be fine.

Thanks for your suggestion and time, and I hope I could explain my rationale. We can close the issue now.

sandulat commented 2 years ago

No worries. Thank you very much for taking your time and opening the issue!