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

Issue: Non-standard install of Node cannot be found when running SSG scripts #862

Open
wale opened this issue Oct 5, 2024 · 2 comments
Open
Labels
bug Something isn't working

Comments

@wale
Copy link

wale commented Oct 5, 2024

Describe the bug
When initialising a project with FrontMatterCMS & Astro, alongside a non-standard version manager (in my case, mise), it throws an error and proceeds to not find content collections.

To Reproduce
Steps to reproduce the behavior:
(requires using a mise (or nvm) installed node or otherwise)

  1. Go to the side bar and click the FrontMatterCMS button.
  2. Click on 'Initialize Project'
  3. Scroll down to 'Create Content Types for your Astro Content Collections'.
  4. 'No Astro Content Collections found'.

Expected behavior
Astro content collections being detected and the script running successfully.

Screenshots
If applicable, add screenshots to help explain your problem.

Device: Fedora Linux 40 x86_64, kernel 6.10.9-200.fc40.x86_64, fish-shell 3.7.0

  • OS: Linux
  • Front Matter CMS Version: tested on beta v10.5.110679225, stable v10.4.1
  • Browser: N/A

image

Additional context
It's possible that this is caused by FrontMatterCMS not having an option to pass a Node binary for its SSG scripts, and calls node based on a shell discovered by VSCode.

const fullScript = `node "${tempScriptPath.fsPath}" "${contentConfigFile.fsPath}"`;

@wale wale added the bug Something isn't working label Oct 5, 2024
@wale wale changed the title Issue: Node cannot be found when running SSG scripts Issue: Non-standard install of Node cannot be found when running SSG scripts Oct 5, 2024
@estruyf
Copy link
Owner

estruyf commented Oct 5, 2024

@wale, your observations are correct. There is currently no option for specifying the Node binary location, only for the custom actions/scripts, but on initialization, it tries to use the general node command.

estruyf added a commit that referenced this issue Oct 28, 2024
@estruyf
Copy link
Owner

estruyf commented Oct 28, 2024

@wale I have implemented a change into the latest beta where it first tries to resolve the node executable path. This is related to the #882 issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants
@estruyf @wale and others