Hello community!
I'm currently working with NSO Developer Studio and the Yangster extension in Visual Studio Code for YANG file development and management. While these tools have significantly enhanced my workflow, I've encountered an issue where VS Code reports many problems with YANG files that are directly provided by Cisco. These files are part of NSO Network Element Drivers (NEDs) and, as far as I understand, should not require modifications.
This situation leads to an overly cluttered problem pane in VS Code, making it harder to focus on genuine issues within my own YANG models. I've been searching for a way to configure VS Code, NSO Developer Studio, or Yangster to ignore these specific directories or files during validation but haven't found a straightforward solution yet.
Does anyone know if there's a way to configure VS Code or the extensions mentioned to ignore certain YANG files or directories during its validation process? Any tips or workarounds that you could share would be greatly appreciated. I'm looking for a method to clean up the validation reports by excluding known good YANG models that are part of the Cisco NED packages.
Thank you in advance for your insights and help!
Accepted Solutions
Hello everyone,
I wanted to provide an update on the issue I reported regarding the problems VS Code was reporting with YANG files that come directly from Cisco, when using NSO Developer Studio and the Yangster extensions.
After some experimentation and adjustments to my workspace setup, I've found a solution that effectively resolves the issue. By placing my service package into its own dedicated workspace within VS Code, separate from the workspace where the Cisco-provided YANG files are located, the validation problems reported by VS Code have ceased.
This approach allows me to work on my service package without the distractions of unrelated validation errors from the NSO NED YANG files. It seems that isolating the development environment for the service package helps Yangster focus on the relevant files without getting tripped up by the broader context of the NSO project's YANG models.
I appreciate the support and suggestions from the community. I hope sharing my solution might help others who encounter similar challenges. It’s a simple workaround that involves reorganizing your project structure for a more focused development experience in VS Code.
Thank you for your insights and assistance!
Hello everyone,
I wanted to provide an update on the issue I reported regarding the problems VS Code was reporting with YANG files that come directly from Cisco, when using NSO Developer Studio and the Yangster extensions.
After some experimentation and adjustments to my workspace setup, I've found a solution that effectively resolves the issue. By placing my service package into its own dedicated workspace within VS Code, separate from the workspace where the Cisco-provided YANG files are located, the validation problems reported by VS Code have ceased.
This approach allows me to work on my service package without the distractions of unrelated validation errors from the NSO NED YANG files. It seems that isolating the development environment for the service package helps Yangster focus on the relevant files without getting tripped up by the broader context of the NSO project's YANG models.
I appreciate the support and suggestions from the community. I hope sharing my solution might help others who encounter similar challenges. It’s a simple workaround that involves reorganizing your project structure for a more focused development experience in VS Code.
Thank you for your insights and assistance!
