sutorio / fs-grow

Grow a directory structure from an array of objects. Testing utility.

Astro Starter Kit: Minimal

npm create astro@latest -- --template minimal

🧑‍🚀 Seasoned astronaut? Delete this file. Have fun!

🚀 Project Structure

Inside of your Astro project, you'll see the following folders and files:

/
├── public/
├── src/
│   └── pages/
│       └── index.astro
└── package.json

Astro looks for .astro or .md files in the src/pages/ directory. Each page is exposed as a route based on its file name.

There's nothing special about src/components/, but that's where we like to put any Astro/React/Vue/Svelte/Preact components.

Any static assets, like images, can be placed in the public/ directory.

🧞 Commands

All commands are run from the root of the project, from a terminal:

Command	Action
npm install	Installs dependencies
npm run dev	Starts local dev server at localhost:4321
npm run build	Build your production site to ./dist/
npm run preview	Preview your build locally, before deploying
npm run astro ...	Run CLI commands like astro add, astro check
npm run astro -- --help	Get help using the Astro CLI

👀 Want to learn more?

Feel free to check our documentation or jump into our Discord server.

fs-grow's Issues

Synchronous methods

There are no synchronous methods, need adding.

API Naming

Review the naming of the main interface & the available standalone functions. FSTree is not a name I like, for example.

Improve the documentation

The documentation is garbage. Improve it, documenting usage, the API etc etc.

Remove flag/mode options

By sticking to the defaults (0o777 for directories, 0o666 for files), can remove a little bit of complexity from the parse/read parts of the code. Does the mode really need to be configured in this library?

Mapping/filtering functionality for the `read` funtions

Allowing mapping/filtering for the read operations would allow them to construct ideal input that could be passed into the parse/write/make functions.

Optimise performance

Should look at ensuring the performance is as good as it can be -- currently it's just been built to work, not to be fast at all. Note that this also suggests I need benchmarking added.

Add single interfaces for the individual `parse`/`read`/`write` functions

Export a single function for each module that can accept configuration parameters.

This means, for example, can have a readFSTree function that can return a compact result or a full result, specify whether to include the full file or not, etc, all based on flags in the config.

Remove encoding option & force UTF-8

Allowing different encodings means that the read function has to guess the encoding using the detect-character-encoding package. This is a big dependency for such a minor thing, requiring UTF-8 encoding may be much simpler.

Set up CI

• set up coverage (Coveralls)
• set up CI runner (Semaphore for now)
• set dependency tracking (Greenkeeper)
• add badges
• review GH actions as CI instead of relying on external service