feat: use named export #251
Conversation
🦋 Changeset detectedLatest commit: 08b5d40 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Add named export `jsoncESLintParser` as the new recommended way to import the parser. This provides a more idiomatic TypeScript import pattern while maintaining full backward compatibility with the existing export structure.
**New usage (recommended):**
```js
import { jsoncESLintParser } from "jsonc-eslint-parser";
```
The `jsoncESLintParser` export includes all parser functionality:
* `meta` and `name` metadata
* `parseJSON` and `parseForESLint` parser functions
* `traverseNodes` for AST traversal
* Utility functions: `getStaticJSONValue`, `isExpression`, `isNumberIdentifier`, `isUndefinedIdentifier`
**Backward compatibility:**
All existing exports remain available and unchanged, so existing code will continue to work without modifications. However, the old pattern will no longer work in the next major version, so users are encouraged to change to the new format.
(This commit message was automatically generated by an LLM.)
|
I don't really understand why this change solves #247 🤔 Does this mean that the original problem could have been avoided by writing it like this? import * as jsoncParser from "jsonc-eslint-parser"; |
|
Yes, you can avoid the type error by doing that, but I already discussed that in the issue you just linked. |
|
I thought that meant the TS errors would be resolved but linting wouldn't actually work, but does it mean that linting still works? |
Linting works with both import forms. This PR fixes the type error.
ESM compatibility is not relevant because as you say, this package is compiled to CJS. |
|
Thanks for the info. Looking at the So I'm closing this PR. Thank you for working on it. |
2 participants
Closes #247.
I tested these changes in a new project with a basic "eslint.config.mjs" file that used "eslint-plugin-jsonc" and "jsonc-eslint-parser" to successfully trigger the "no-dupe-keys" rule on a "test.jsonc" file.
I tested both the old default format and the new named export format, and both were able to trigger "no-dupe-keys".
I updated the README to update the information on the recommended way to consume the plugin (via the named export). The other changes in the README I made are just artifacts due to it not being properly formatted with Prettier. (As an aside, I think that is a bug in this project, as unformatted files should typically cause an error in CI.)