Skip to content
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

💡 RFC: Standardize path imports #252

Closed
natemoo-re opened this issue May 26, 2021 · 3 comments
Closed

💡 RFC: Standardize path imports #252

natemoo-re opened this issue May 26, 2021 · 3 comments

Comments

@natemoo-re
Copy link
Member

Small suggestion: I’ve noticed that we all have different styles when it comes to expanding different methods for node:path. I’ve even seen us have local variables named path that cause us to remap node:path to something else entirely to avoid conflict. It’s just different in every file. Here, I think renaming posix as path may be a little unexpected here, especially if non-POSIX is needed.

What do you think about just standardizing import path from 'path' in the project everywhere? It’s a little more verbose but it’s predictable, and we don’t need to keep changing import statements every time we need a new method

Originally posted by @drwpow in #231 (comment)

@drwpow
Copy link
Member

drwpow commented May 26, 2021

Related: should we just use import fs from 'fs'; as well, too? I don’t feel as strongly about fs but it follows a similar pattern of every module renames common methods differently

@matthewp
Copy link
Contributor

@drwpow I think we should be using the promises versions of fs methods (I think we are for the most part now).

@drwpow
Copy link
Member

drwpow commented May 26, 2021

Yeah I agree with fs.promises everywhere. It’s just exists() that’s left out. I’d be fine with { existsSync, promises as fs } or something.

@FredKSchott FredKSchott changed the title Standardize path imports 💡 RFC: Standardize path imports Jun 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants