-
Notifications
You must be signed in to change notification settings - Fork 127
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
generate sourcemaps #1630
Comments
Thank you for opening the issue. I believe this is an important improvement for configuring the ecosystem. 👍 |
Hey @Peefy , let me give this a shot! I will first try a CLI flag implementation for this, lets see how that goes! |
I have opened a draft PR as I iteratively build the solution for this. Will ping for a review once I am ready! |
I’ve been working on implementing the ability to generate sourcemaps via the CLI, as outlined in this issue. The current implementation tracks and writes the mapping between the source lines and the generated YAML lines. This has taken over 12 hours of work so far, and I’d greatly appreciate any feedback on the approach and implementation details before proceeding further to write tests for it. Since this feature is part of the v1.0 release milestone (due January 31st), I want to ensure we’re on the right track early on. Let me know your thoughts! |
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: