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

failed first compilation: operation not permitted, symlink #25

Open
sheam opened this issue Oct 1, 2024 · 1 comment
Open

failed first compilation: operation not permitted, symlink #25

sheam opened this issue Oct 1, 2024 · 1 comment

Comments

@sheam
Copy link

sheam commented Oct 1, 2024

The first time a ts file is attempted to load, I get the following error:

Error: EPERM: operation not permitted, symlink 'C:\Users\coder\source\repos\ProjectFolder\node_modules' -> 'C:\Users\coder\source\repos\ProjectFolder\.config-ts-cache\path\to\myproject.confing

I am loading the file like this:

  const configPath = path.join(process.cwd(), configFileScaffoldingPath);
  const cachePath = path.join(
    process.cwd(),
    '.config-ts-cache',
    'path/to/myproject.confing`
  );
  try{
    const config = loadTsConfig<IConfigFile<TInput>>(configPath, cachePath, true);
    if(config) {
       console.log('SUCCESS');
   } else { 
      console.log('EMPTY');
   }
 } catch(e) { 
   console.log(e);  //this is the error that is happening.
 }

Even though the exception is thrown, the cache is created, so I think compilation is working.

Subsequent runs loads of that file are fine.

If I delete the cache folder, I get the error again (first time). I can also recreate the error by modifying my config file, and running again, so compilation is forced.

Not specifying a cacheFolder makes no difference.

It may also be worth noting that this happens when I compile my app, then publish it (as an npm bin app), and run it from another project.

I am on windows 11.

use version 0.2.8-rc1, but have repeated on 0.2.6 and 0.2.4.

@sheam
Copy link
Author

sheam commented Oct 2, 2024

It looks like changing the symLinkForce() function to use type 'junction' on windows fixes the issue:

/** create a symlink, replacing any existing linkfile */
export function symLinkForce(existing: string, link: string): void {
  if (fs.existsSync(link)) {
    if (!fs.lstatSync(link).isSymbolicLink()) {
      throw `symLinkForce refusing to unlink non-symlink ${link}`;
    }
    fs.unlinkSync(link);
  }
  const linkType = process.platform === 'win32' ? 'junction' : undefined;
  fs.symlinkSync(existing, link, linkType);
}

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

1 participant