cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
314
Views
4
Helpful
2
Replies

Configuring VS Code to Ignore Validation on Cisco-provided YANG Files

ndmitri
Level 1
Level 1

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!

Screenshot 2024-03-17 at 10.15.18 PM.png 

1 Accepted Solution

Accepted Solutions

ndmitri
Level 1
Level 1

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!

Screenshot 2024-03-19 at 8.04.00 PM.png

View solution in original post

2 Replies 2

Torbjørn
Spotlight
Spotlight

There is no good way to achieve with Yangster and NSO Code Studio unfortunately. VScode seems to have "delegated" problem filtering to extension authors according to this git issue: https://github.com/microsoft/vscode/issues/22289

Your options are then either filtering with the "filter" function in the problems pane, or excluding the files completely with the files.exclude setting. Note that excluding the files will affect more than just the problem reporting. There is also an option to configure the LSP to exclude the paths, but this will also break some LSP/linting functionality.

Happy to help! Please mark as helpful/solution if applicable.
Get in touch: https://torbjorn.dev

ndmitri
Level 1
Level 1

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!

Screenshot 2024-03-19 at 8.04.00 PM.png