diff --git a/.github/CONTRIBUTING.es.md b/.github/CONTRIBUTING.es.md
index 3b941b47..2d661b57 100644
--- a/.github/CONTRIBUTING.es.md
+++ b/.github/CONTRIBUTING.es.md
@@ -1,14 +1,10 @@
-**_(Este doc está en proceso de desarrollo)_**
-
# Cómo contribuir a NPKILL 🎉
Sé que lo que voy a decir es lo típico, pero es realmente maravilloso que estés leyendo estas líneas. Quiere decir que estás interesad@ en ayudar a mejorar Npkill, _o quizá simplemente estés aquí por curiosidad `cof cof`_.
Sea por la razón que sea, eres bienvenid@. A continuación te explico las pautas recomendadas a la hora de contribuir.
----
-
-# Consideraciones habituales
+## Consideraciones habituales
- Seguir este protocolo ayuda a evitar trabajar en vano. Sería una pena dedicar horas a un pull request y que tengamos que rechazarlo porque ya hay alguien trabajando en un issue similar.
@@ -20,7 +16,7 @@ Sea por la razón que sea, eres bienvenid@. A continuación te explico las pauta
- Siempre que sea posible, añade tests, tests y... ¡Más tests! tests tests tests tests tests tests tests tests tests tests tests
-# Nueva feature
+## Nueva feature
1. Si quieres contribuir con una nueva feature, asegúrate de que no hay un issue anterior de otra persona trabajando en lo mismo.
@@ -28,21 +24,19 @@ Sea por la razón que sea, eres bienvenid@. A continuación te explico las pauta
3. Espera a que la comunidad se pronuncie, y a que algún miembro apruebe tu propuesta (decisión que se tendrá un cuenta por la comunidad).
-¡Bien! ¡Luz verde para picar!
-
4. Haz un fork de este proyecto.
5. Crea una nueva rama siguiendo las convenciones recomendadas.
6. Escribe el código y crea commits de forma regular siguiendo la convención recomendada.
-7. Crea un PULL REQUEST utilizando **master como rama base**.
+7. Crea un PULL REQUEST utilizando **main como rama base**.
Como título, utiliza uno igual o similar al que utilizaste en la creación del issue, y en la descripción, cualquier información que consideres relevante junto al enlace al issue y el mensaje "close". Ejemplo: close #numeroIssue
[más info](https://help.github.com/en/articles/closing-issues-using-keywords)
-# Convenciones
+## Convenciones
-## Ramas de git
+### Ramas de git
Recomendamos utilizar la siguiente nomenclatura siempre que sea posible:
@@ -50,7 +44,7 @@ Recomendamos utilizar la siguiente nomenclatura siempre que sea posible:
- fix/lstat-crash
- docs/improve-readme
-## Mensajes de git
+### Mensajes de git
Asegúrate de pensar bien el mensaje de cada commit.
Todos los commits deben utilizar una convención similar a la de `Angular`. [Aquí tienes todas las reglas](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional#type-enum)
@@ -63,13 +57,14 @@ Todos los commits deben utilizar una convención similar a la de `Angular`. [Aqu
_[Some points extracted from Atom doc](https://github.com/atom/atom/blob/master/CONTRIBUTING.md#git-commit-messages)_
-## Código
+### Código
Es importante aplicar los principios del código limpio.
Si utilizas `VS Code`, a continuación tienes algunos add-ons que recomendamos:
-- TSLint: Te permite saber si estás incumpliendo algunas de las _reglas de código_ (no utilizar var, utilizar const siempre que sea posible, tipar siempre las variables etc.)
-- CodeMetrics: Calcula la complejidad de los métodos, para asegurar que cada función hace únicamente 1 cosa. (verde es ok, amarillo es meh, rojo es oh god why)
+- **TSLint**: Te permite saber si estás incumpliendo algunas de las _reglas de código_ (no utilizar var, utilizar const siempre que sea posible, tipar siempre las variables etc.)
+
+- **CodeMetrics**: Calcula la complejidad de los métodos, para asegurar que cada función hace únicamente 1 cosa. (verde es ok, amarillo es meh, rojo es oh god why)
Si utilizas otro IDE, probablemente haya add-ons parecidos disponibles.
\ No newline at end of file
diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md
index 6ac11023..cf86b667 100644
--- a/.github/CONTRIBUTING.md
+++ b/.github/CONTRIBUTING.md
@@ -1,25 +1,21 @@
-**_(this doc is under construction)_**
-
# How to contribute on NPKILL 🎉
I know that what I am going to say sounds like something typical, but I am sincerely glad that you are reading this, because that means that you are interested in helping to improve Npkill, _or you may simply be here out of curiosity `cof cof`_.
Anyway, you are sincerely welcome. I will try to explain the recommended guidelines to contribute.
----
-
-# Common considerations
+## Common considerations
- Following this protocol helps to avoid working in vain. It would be a shame to dedicate hours to a pull request and have to reject it because there is already someone working on a similar issue.
--Unless they are minor and fast modifications, try to let everyone know that you are modifying something by opening an issue for example, or consulting the [projects](https://github.com/voidcosmos/npkill/projects)
+- Unless they are minor and fast modifications, try to let everyone know that you are modifying something by opening an issue for example, or consulting the [projects](https://github.com/voidcosmos/npkill/projects).
- Change only the necessary lines for your modification. This will help to avoid conflicts, and in case of there being any, it will be easier to solve them.
-- Make sure you to run `npm install`, because some development packages are meant to maintain harmony. Prettier, for example, makes sure that in each commit the files are well indented, and Commitlint makes sure that your messages follow the convention.
+- Make sure to run `npm install`, because some development packages are meant to maintain harmony. Prettier, for example, makes sure that in each commit the files are well indented, and Commitlint makes sure that your messages follow the convention.
-- Whenever possible, write tests, tests and more tests! tests tests tests tests tests tests tests tests tests tests tests
+- Whenever possible, write tests, tests and more tests! tests tests tests tests tests tests tests tests tests tests tests.
-# New feature
+## New feature
1. If you want to contribute to a new feature, make sure that there isn't a previous issue of someone working on the same feature.
@@ -27,20 +23,18 @@ Anyway, you are sincerely welcome. I will try to explain the recommended guideli
3. Wait for the community to give an opinion, and for some member to approve your proposal (a decision that will be taken into the community and future plans).
-Yay! Green light to work!
-
4. Fork this project.
-5. Create a new branch following the [recommended conventions]()
+5. Create a new branch following the [recommended conventions](#conventions)
-6. Write code and create commits regularly following the [recommended convention]()
+6. Write code and create commits regularly following the [recommended convention](#conventions)
-7. Create a PULL REQUEST using **master as the base branch**.
+7. Create a PULL REQUEST using **main as the base branch**.
As a title, use the same (or similar) one you used in the creation of the issue, and in the description, any information that you consider relevant next to the link of the issue and "close" text (example: close #issueNumber) [more info](https://help.github.com/en/articles/closing-issues-using-keywords)
-# Conventions
+## Conventions
-## git branch
+### git branch
I recommend using the following nomenclature whenever possible:
@@ -48,7 +42,7 @@ I recommend using the following nomenclature whenever possible:
- fix/lstat-crash
- docs/improve-readme
-## git messages
+### git messages
Be sure to take your time thinking about the message for each commit.
All commits must use a convention similar to `Angular`. [Here all the rules](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional#type-enum)
@@ -60,13 +54,14 @@ All commits must use a convention similar to `Angular`. [Here all the rules](htt
_[Some points extracted from Atom doc](https://github.com/atom/atom/blob/master/CONTRIBUTING.md#git-commit-messages)_
-## code
+### code
It is important to apply the principles of clean code.
If you use `VS Code`, there are some add-ons that I recommend:
--TSLint: Lets you know if you are breaking any of the _coding rules_ (do not use var, use const if possible, if some type has not been defined etc)
-- CodeMetrics: Calculates the complexity of the methods, to ensure that your functions do only 1 thing. (green is ok, yellow is meh, red is oh god why)
+- **TSLint**: Lets you know if you are breaking any of the _coding rules_ (do not use var, use const if possible, if some type has not been defined etc)
+
+- **CodeMetrics**: Calculates the complexity of the methods, to ensure that your functions do only one thing. (green is ok, yellow is meh, red is oh god why)
If you use a different IDE, there are probably similar add-ons available.
diff --git a/.github/CONTRIBUTING.pt.md b/.github/CONTRIBUTING.pt.md
new file mode 100644
index 00000000..67112d62
--- /dev/null
+++ b/.github/CONTRIBUTING.pt.md
@@ -0,0 +1,67 @@
+# Como contribuir para o NPKILL 🎉
+
+Eu sei que o que vou dizer pode parecer algo típico, mas estou sinceramente feliz por você estar lendo estas linhas, porque isso significa que você está interessado em ajudar a melhorar o Npkill, _ou talvez você esteja aqui apenas por curiosidade `cof cof`_.
+De qualquer forma, você é muito bem-vindo. Vou tentar explicar as diretrizes recomendadas para contribuir.
+
+## Considerações comuns
+
+- Seguir este protocolo ajuda a evitar trabalhar em vão. Seria uma pena dedicar horas a um pull request e ter que recusá-lo porque já existe alguém trabalhando em uma issue semelhante.
+
+- A menos que sejam modificações pequenas e rápidas, tente avisar a todos que você está modificando algo abrindo uma issue, por exemplo, ou consultando os [projetos](https://github.com/voidcosmos/npkill/projects).
+
+- Altere apenas as linhas necessárias para a sua modificação. Isso ajuda a evitar conflitos e, caso existam, torna mais fácil resolvê-los.
+
+- Certifique-se de executar `npm install`, porque alguns pacotes de desenvolvimento são usados para manter a harmonia. O Prettier, por exemplo, garante que todos os arquivos fiquem bem indentados em cada commit, e o Commitlint garante que suas mensagens sigam a convenção.
+
+- Sempre que possível, escreva testes, testes e mais testes! testes testes testes testes testes testes testes testes testes testes testes.
+
+## Nova funcionalidade
+
+1. Se você quiser contribuir com uma nova funcionalidade, certifique-se de que não exista uma issue anterior com alguém trabalhando na mesma funcionalidade.
+
+2. Em seguida, abra uma issue explicando o que você deseja incorporar e os arquivos que você acha que precisará modificar a priori.
+
+3. Aguarde a comunidade dar uma opinião e algum membro aprovar sua proposta (uma decisão que será tomada pela comunidade e pelos planos futuros).
+
+4. Faça um fork deste projeto.
+
+5. Crie uma nova branch seguindo as [convenções recomendadas](#convenções).
+
+6. Escreva o código e crie commits regularmente seguindo a [convenção recomendada](#convenções).
+
+7. Crie um PULL REQUEST usando **main como branch base**.
+ Como título, use o mesmo (ou semelhante) que você usou na criação da issue, e na descrição, qualquer informação que você considere relevante junto com o link da issue e o texto "close" (exemplo: close #issueNumber) [mais informações](https://help.github.com/en/articles/closing-issues-using-keywords).
+
+## Convenções
+
+### branch do git
+
+Eu recomendo usar a seguinte nomenclatura sempre que possível:
+
+- feat/sort-results
+- fix/lstat-crash
+- docs/improve-readme
+
+### mensagens de commit
+
+Certifique-se de reservar um tempo para pensar na mensagem de cada commit.
+Todos os commits devem usar uma convenção semelhante à do Angular. [Aqui estão todas as regras](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional#type-enum)
+
+- Use o tempo presente ("add feature" e não "added feature")
+- Use o modo imperativo ("move cursor to..." e não "moves cursor to...")
+- Limite a primeira linha a 72 caracteres ou menos
+- Faça referência a issues e pull requests liberalmente após a primeira linha
+
+ _[Alguns pontos extraídos do documento do Atom](https://github.com/atom/atom/blob/master/CONTRIBUTING.md#git-commit-messages)_
+
+### código
+
+É importante aplicar os princípios de código limpo.
+
+Se você usar o VS Code, existem algumas extensões que eu recomendo:
+
+- **TSLint**: informa se você está quebrando alguma das _regras de codificação_ (não use var, use const quando possível, se algum tipo não foi definido etc.)
+
+- **CodeMetrics**: calcula a complexidade dos métodos, para garantir que suas funções façam apenas uma coisa. (verde é ok, amarelo é mediano, vermelho é “meu Deus, por quê?”)
+
+Se você usar outra IDE, provavelmente existem extensões semelhantes disponíveis.
diff --git a/API.md b/API.md
index 584331f2..ae41e22a 100644
--- a/API.md
+++ b/API.md
@@ -221,7 +221,7 @@ let files: {
}[] = [];
npkill
- .startScan$('/home/user/projects/', { target: '.nx' })
+ .startScan$('/home/user/projects/', { targets: ['.nx'] })
.pipe(
// Step 1: For each scan result, get the newest file
mergeMap((scanResult) =>
diff --git a/README.es.md b/README.es.md
index 4c2f8cac..44c076c0 100644
--- a/README.es.md
+++ b/README.es.md
@@ -17,13 +17,6 @@
Esta herramienta te permite listar cualquier directorio _node_modules_ que haya en tu sistema, además del espacio que ocupa. Entonces puedes seleccionar los que quieras borrar para liberar espacio. ¡Yay!
-## i18n
-
-Nos estamos esforzando por internacionalizar la documentación de Npkill. Aquí tienes una lista de las traducciones disponibles:
-
-- [Español](./README.es.md)
-- [Português](./README.pt.md)
-
## Table of Contents
- [Características](#features)
diff --git a/README.id.md b/README.id.md
index 8c868a45..c3ed04f3 100644
--- a/README.id.md
+++ b/README.id.md
@@ -17,15 +17,6 @@
Alat ini memungkinkan Anda untuk mencantumkan semua direktori _node_modules_ di sistem Anda, serta ruang yang mereka gunakan. Anda kemudian dapat memilih mana yang ingin Anda hapus untuk mengosongkan ruang penyimpanan. Yay!
-## i18n
-
-Kami berusaha untuk menerjemahkan dokumen Npkill ke berbagai bahasa. Berikut daftar terjemahan yang tersedia:
-
-- [Español](./README.es.md)
-- [Indonesian](./README.id.md)
-- [Portugis](./README.pt.md)
-- [Turki](./README.tr.md)
-
## Daftar Isi
- [Fitur](#features)
diff --git a/README.md b/README.md
index 314c5676..06fc99ef 100644
--- a/README.md
+++ b/README.md
@@ -251,9 +251,9 @@ npm run start -- -f -e
# :bookmark_tabs: API
-The api allows you to interact with npkill from node to create your own implementations in your scripts (automations, for example).
+The API allows you to interact with npkill from node to create your own implementations in your scripts (automations, for example).
-You can check the basic API [here](./API.md) or on the web (comming soon).
+You can check the basic API [here](./API.md) or on the web (coming soon).
diff --git a/README.pt.md b/README.pt.md
index c9efaea8..31da0cb0 100644
--- a/README.pt.md
+++ b/README.pt.md
@@ -15,14 +15,7 @@
-Desenvolvemos o npkill em nosso tempo livre, porque somos apaixonados pelo setor de programação. Amanhã, gostaríamos de nos dedicar mais a isso, mas antes, temos um longo caminho a percorrer.
+Desenvolvemos o npkill em nosso tempo livre, porque somos apaixonados por programação. No futuro, gostaríamos de nos dedicar mais a isso, mas antes, temos um longo caminho a percorrer.
Continuaremos a fazer as coisas de qualquer maneira, mas as doações são uma das muitas formas de apoiar o que fazemos.
diff --git a/README.tr.md b/README.tr.md
index df07b734..dd5980a4 100644
--- a/README.tr.md
+++ b/README.tr.md
@@ -17,15 +17,6 @@
Bu araç, sisteminizdeki tüm _node_modules_ dizinlerini ve kapladıkları alanı listelemenizi sağlar. Daha sonra, hangilerini silmek istediğinizi seçerek yer açabilirsiniz. Yaşasın!
-## i18n
-
-Npkill dokümantasyonunu uluslararası hale getirmek için çaba gösteriyoruz. İşte mevcut çevirilerin listesi:
-
-- [Endonezce](./README.id.md)
-- [İspanyolca](./README.es.md)
-- [Portekizce](./README.pt.md)
-- [Türkçe](./README.tr.md)
-
## İçindekiler
- [Özellikler](#features)
diff --git a/docs/npkillrc.md b/docs/npkillrc.md
index 94fd557f..22566e89 100644
--- a/docs/npkillrc.md
+++ b/docs/npkillrc.md
@@ -74,7 +74,7 @@ npkill --config /path/to/your/config.json
Absolute path from which the search will begin.
```json
-"rootdir": "/home/user/my-projects/"
+"rootDir": "/home/user/my-projects/"
```
### exclude
diff --git a/docs/profiles.md b/docs/profiles.md
index e8366b54..94b39702 100644
--- a/docs/profiles.md
+++ b/docs/profiles.md
@@ -6,11 +6,11 @@ While these directories are **generally safe to delete**, it all depends on thei
- Profiles are opt-in via `--profiles` (comma-separated). Example: `--profiles node,python`.
- Only directory base names are matched (the last path segment) (more advanced heuristics will be implemented in the future).
-- All targets below are rebuildable caches, dependencies, or compiled outputs. So doesnt should have any problem deleting it. But before delete, peek if is secure to remove for your case.
+- All targets below are rebuildable caches, dependencies, or compiled outputs, so they generally should not cause any issues when deleted. But before deleting, check whether it is safe to remove them in your case.
Default behavior
-- By default (no `--profiles`), npkill use the `node` profile.
+- By default (no `--profiles`), npkill uses the `node` profile.
Special profile: all