-
Notifications
You must be signed in to change notification settings - Fork 24
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
More strict on what is considered a builtin - Fixes #16 #17
Conversation
Relates to IanVS#16 Looks like a combination of config options are conflicting? Not sure why it triggers on CLI vs API for me, but the run_spec is able to reproduce it in this repo.
@fbartho I've invited you as a collaborator, so you can make branches without a fork, to make it easier to collaborate. I'm taking a look into this now. I updated my project at work to the latest version, and running prettier in the cli does not throw any errors, so at least it doesn't seem like something that broke in the latest release. |
This appears to be related to |
|
How about changing this to `^(${builtinModules.join("|")}|${builtinModules.map(module => 'node:'+module).join("|")})$` That resolves to
|
Previously, we could match on portions of relative paths. This ensures that only an entire match of the builtin module names will be considered.
Yep, exactly. Although I used a non-capturing group. I also simplified down the test case a bit. |
src/constants.ts
Outdated
@@ -16,7 +16,7 @@ export const chunkTypeOther = 'other'; | |||
* where the not matched imports should be placed | |||
*/ | |||
export const THIRD_PARTY_MODULES_SPECIAL_WORD = '<THIRD_PARTY_MODULES>'; | |||
export const BUILTIN_MODULES = builtinModules.join('|'); | |||
export const BUILTIN_MODULES = `^(?:${builtinModules.join('|')})$`; |
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.
Careful, this is missing support for node protocol imports, e.g. require("node:fs")
`^(${builtinModules.join("|")}|${builtinModules.map(module => 'node:'+module).join("|")})$`
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.
Or perhaps a bit simpler:
`^(node:)?(${builtinModules.join("|")})$`
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 should have run all the tests before pushing it up. :)
I tweaked the regex a bit to allow an optional node:
prefix.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
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 see the fix now)
Oh this is interesting. I guess that |
I guess the other option is to stop supporting node 12. It's EOL, after all. I propose that we remove it from our tests, at least. What do you think, @blutorange, @fbartho? |
I'm certainly supportive of only explicitly supporting N-1 on stable node release lines. -- Like maybe it works on node-12, but we shouldn't try to maintain support for it! |
The PR is green! Please let me know if you want me to strip out the test case, or move it somewhere, or if this PR is ready to go! |
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.
Looks good to me, thanks both of you.
Relates to #16
Looks like a combination of config options are conflicting?
Not sure why it triggers on CLI but not in IDE for me, but the run_spec is able to reproduce it in this repo.