在当前文件夹中运行依赖项，而不是VSCODE目录
我希望围绕我们一直在研究的CLI工具构建VSCODE扩展。示例命令是
myCLI retrieve SourceName
将其从特定目录（例如C：/workspace/myproject）运行，该目录已设置并包含某些配置参数的设置文件。
该CLI的设计是直接暴露了称为“检索”的方法（例如“检索”），因此CLI本身也是包装器。
当尝试直接从VS代码扩展名调用这些方法时，它总是在 c：/program文件/Microsoft vs Code 目录中进行检查，我知道这就是扩展是从中示意的。
现在，问题：我有什么办法强迫我们任何时候称呼该方法（例如“检索”），以查看当前的工作空间文件夹（ c：/workspace/myproject < /strong> ），而不是VS代码一（ c：/program Files/Microsoft vs Code ）？
可能会更改答案的注释
- commonj（尚未尚未ESM），
- 我们目前无法通过完整的合格路径（例如C：/workspace/myproject），它仅在寻找./settings.json，因为这取决于CLI的位置 我想
- 避免直接调用CLI，因为我想将许多CLI功能直接带入VS代码扩展中以提高用户友好。
I am looking to build a VSCode Extension around a CLI tool which we have been working on. An example command would be
myCLI retrieve SourceName
This would be run from a specific directory (for example c:/workspace/myproject) which has been setup and contains a settings.json file for some config arguments.
This CLI has been designed that the methods which are called (for example 'retrieve') are exposed directly so the CLI itself is a wrapper also.
When trying to call these methods directly from a VS Code Extension, it is always checking in the C:/Program Files/Microsoft VS Code directory, which I understand is where the Extension is excuting from.
Now, the question: Is there any way for me to force that any time we call the method (for example 'retrieve') that this would look into the current workspace folder (C:/workspace/myProject) , and not the VS Code one (C:/Program Files/Microsoft VS Code)?
Notes which may change answers
- CommonJS (not yet ESM)
- We currently cannot pass in a full qualified path (for example C:/workspace/myProject), it is only looking for ./settings.json since it depends on where the CLI has bene run from
- I want to avoid calling the CLI directly, as I would like to bring many of the CLI features into the VS Code Extension directly to improve user friendliness.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论