-
Notifications
You must be signed in to change notification settings - Fork 411
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
Single dialect import #511
Conversation
Don't just re-export all, as that will easily lead to unwanted exports, like the export of formatters map, which should not have been publicly exposed.
Also add comment to avoid removing this syntax in the future
export * from './allDialects.js'; | ||
|
||
// NB! To re-export types the "export type" syntax is required by webpack. | ||
// Otherwise webpack build will fail. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there's an eslint-typescript rule here we can leverage, use-consistent-type-exports
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can make a PR to update eslint rules soon
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good find. I added the rule on my own. Seems to work just as needed.
New API for supporting import of a single dialect. As discussed in #484, I've added a separate formatting function that works a bit differently than the old one.
The old
format()
function works like before, with the exception thatlanguage
parameter can only be string:The new
formatDialect()
only works with explicitly imported dialect:formatDialect()
is also used under the hood by the oldformat()
function.I chose to name it
formatDialect
to make it clear that it accepts adialect
config option (instead oflanguage
). This also aligns with the naming of types, where the actual value is aDialectOptions
object. (Originally I thought of usinglanguage
option for both, but this seemed too confusing - an option expecting one type in one context and another type in another context - so I opted for clearly distinct option names).Fixes #452