tomprogers / filesystem-path Goto Github PK

Last time I used Windows, every path began with a "drive letter":

C:\Documents and Settings\tomprogers\Desktop\file.ext

There's no equivalent on *nix filesystems.

It's almost certainly very bad to treat "C:" as the first "folder". Ideally it'll be represented as an extra path prop, perhaps drive or something.

Research these things.

• are they always a single letter? (i.e. keyspace of 26)
• do they always include the colon?
• what are they really called?
• is this a Windows thing? or an NTFS thing? what technology is responsible for them in the Windows ecosystem?

Add the other stuff I have planned. Some of this will take a little research.

String methods

• replace() // like String.replace, operates on raw path, returns self

RegExp-facing methods (treats segments as lines unless /g flag)

• TODO: see String methods that take regexes
• test() //> bool? or would it be the string method
• match() //>
• search()
• exec()

Array methods (operate on folders)

• slice()
• splice()
• push()
• pop()
• shift()
• unshift()

Static class methods

• canonicalize( directory, filename, sep ) // resolves './' & '../'
• escape( directory, filename, sep ) // TODO: research what folks will need

Tests are decent, but the experimental design of each suite is isolated. This seems bad because the variety of paths encountered in the wild is presumably the same regardless of which method we're testing.

So, I want to standardize the set of scenarios that is checked across the board.

1. divide each test suite into two sections:

   1. validate function sig, returns/throws, and own custom logic
   2. assert correct answers to common set of scenarios:
      • typical cases, like /path/to/some.fil
      • unusual cases, like dotfiles & no-directory etc; hunt through extant tests for these
      • bug-triggering cases, like /etc/pam.d/, plus accumulate every specific case associated with a real bug

2. find a better way to handle nix/win testing

Everything should be tested against both separators, but it'd be nice if that didn't require literally doubling the size of the test code. Is there a trustworthy way to generate the second set of cases based on the first, so that every test is automatically "cross-platform"?

new FSP( ...paths? , filename?, sep? )

• concatenates all paths
  • throws if anything other than first path is absolute
  • does not normalize anything, just combine and then dismantle

I think this will be 100% backwards-compatible with v0.3.

Notes on updates I want to make to the documentation:

• cover the pam.d case in the "guessing is bad" section
• actual sig documentation for every method
• show that FSPs can be used where strings are used because of toString