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

Name feedback and a few suggestions #3

Closed
NathanielHill opened this issue Feb 14, 2020 · 9 comments
Closed

Name feedback and a few suggestions #3

NathanielHill opened this issue Feb 14, 2020 · 9 comments
Labels
enhancement New feature or request

Comments

@NathanielHill
Copy link

I don't think the name is that bad, but I would recommend dropping the -cli suffix.

I've had something like this in mind ever since I ran across arkit

I think this is a great idea and could greatly simplify things for teams in the same ways prettier has.

I'm imagining adding this into my workflow as a pre-commit stage using husky + lint-staged.

Would be nice to have a flag that causes a failure on unused files, so cruft doesn't accumulate.

I think people will have strong preferences which could be solved with a couple config options, but I imagine having a consistent and enforced structure is almost universally preferable.

👍

@JuanMarchetto
Copy link

JuanMarchetto commented Feb 14, 2020

I think this is a great idea and i'll try to contribute.
I'm also think that maybe this will be great whit some config options
regarding names i try to think in alternatives but i only come up with this two options:
Structurify
Entropy

@NathanielHill
Copy link
Author

Another suggestion:

Be able to specify starting point and some logic to handle monorepos.

For example, a lot of projects using yarn workspaces will have structures like @scope/ui @scope/web @scope/ui etc

@NathanielHill
Copy link
Author

Would be nice to have some logic on how shared dependencies are handled. For instance, whether they should always be moved to the @scope/shared workspace, or only moved to the shared workspace if they're used across multiple workspaces and have local shared otherwise.

@NathanielHill
Copy link
Author

I can also imagine certain frameworks have some idiosyncrasies that won't follow the structure, so ability to ignore those.

And, if running in the root, being able to ignore certain .js configuration files

@capaj
Copy link

capaj commented Feb 15, 2020

how about "Filer"? Has a similar ring to it as "Prettier"

@AnatoleLucet
Copy link
Collaborator

@capaj I like this name. But unfortunately it's already taken from another package :(

@capaj
Copy link

capaj commented Feb 15, 2020

@AnatoleLucet we could create a scope on npm @filer and put the cli as @filer/cli.
Also if the project picks up and we have other language than TS/JS plugins, they can be published under that scope-like for example @files/sass or @filer/less

BTW that scope is still free: https://www.npmjs.com/~filer

@AnatoleLucet
Copy link
Collaborator

Why not. With a bin named filer this is doable.

@sQVe
Copy link
Collaborator

sQVe commented Feb 18, 2020

We've now changed name to destiny and have multiple issues with features for the future. 🎉

I'm closing this issue.

@sQVe sQVe closed this as completed Feb 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants