You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe:
kcl can be used to trivially generate yaml files and other structured data. For any given yaml file that lives as part of another ecosystem (e.g. kubernetes manifests, or ansible playbooks), there exist linters that are able to describe errors with the output yaml. While it's straightforward to 'kcl run' then run the output through the linter, to resolve linter errors, I then must then determine the kcl file line number that generated a particular output file line number. Additionally, if I'm using an IDE, the IDE won't be able to display any errors on the line number of the generated source file.
Describe the feature you'd like:
While an end to end solution requires more ecosystem changes, the first step is to have kcl be able to output sourcemaps in addition to it's normal output. Sourcemaps, while part of the ES standard, are language and platform agnostic ways of describing original source locations from generated code.
This could potentially look like:
$ kcl run -o outputfile.yaml --sourcemap outputfile.map
After sourcemaps are available, upstream tools can be modified to accept map files, which can be used to print errors that reference the kcl line numbers, or highlight generated file linter errors. This approach is common in the transpiled javascript world.
Describe alternatives you've considered:
The alternative is to generate the files, run tools over the generated files, and map the line number messages back to the generated kcl code manually.
Feature Request
Is your feature request related to a problem? Please describe:
kcl can be used to trivially generate yaml files and other structured data. For any given yaml file that lives as part of another ecosystem (e.g. kubernetes manifests, or ansible playbooks), there exist linters that are able to describe errors with the output yaml. While it's straightforward to 'kcl run' then run the output through the linter, to resolve linter errors, I then must then determine the kcl file line number that generated a particular output file line number. Additionally, if I'm using an IDE, the IDE won't be able to display any errors on the line number of the generated source file.
Describe the feature you'd like:
While an end to end solution requires more ecosystem changes, the first step is to have kcl be able to output sourcemaps in addition to it's normal output. Sourcemaps, while part of the ES standard, are language and platform agnostic ways of describing original source locations from generated code.
This could potentially look like:
Or using the file api:
After sourcemaps are available, upstream tools can be modified to accept map files, which can be used to print errors that reference the kcl line numbers, or highlight generated file linter errors. This approach is common in the transpiled javascript world.
Describe alternatives you've considered:
The alternative is to generate the files, run tools over the generated files, and map the line number messages back to the generated kcl code manually.
Teachability, Documentation, Adoption, Migration Strategy:
The text was updated successfully, but these errors were encountered: