You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/about/roadmap.md
+6-5Lines changed: 6 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,20 +8,21 @@ We'll expand (and rarely, but not impossibly, shrink) this roadmap as we make pr
8
8
9
9
This page also lists all minor and major releases since 2.X. Patches aren't listed, and most bugfixes aren't included (as we don't "plan" to fix bugs).
10
10
11
-
## Upcoming major release
11
+
## 4.X
12
12
13
-
These are early plans; however we're already working on 4.0 [from this branch](https://github.com/FuckingNode/FuckingNode/tree/v4). Expect this list to change over time and/or get removals.
13
+
### Version 4.0 (Released)
14
14
15
-
-[] New features
16
-
-[]`build`, to automate building. Especially useful in JavaScript. This would have a text-config file to define what tasks to run for building a project. It could be used in combination with `release`.
15
+
-[x] New features
16
+
-[x]`build`, to automate building. Especially useful in JavaScript. This would have a text-config file to define what tasks to run for building a project. It could be used in combination with `release`.
17
17
-[x]`release` support for Cargo.
18
-
-[ ] Dual release support: using the `FnCPF` from the interop layer to allow publishing the same JavaScript package to both npm and jsr. This would be really helpful as jsr downloads do not always work well with npm projects.
18
+
-[ ] Dual release support: using the `FnCPF` from the interop layer to allow publishing the same JavaScript package to both npm and jsr. This would be really helpful as jsr downloads do not always work well with npm projects. (_Not done, rescheduled for v4.1_)
19
19
-[x] Rebuild `commit`, so you tell it what files to commit and it:
20
20
-[x] Un-stages anything else to avoid committing randomly staged files.
21
21
-[x] Doesn't require you to stage the files _before_ (making it useless, as `git commit -a -m` is also just one command), and lets you stage files from the own command.
22
22
-[x] Runs pre-commit tasks _before_ staging, making them actually useful.
23
23
-[X] Allow for DIR-based running; in simpler terms, compute things like `fkn stats` to `fkn stats --self` or `fkadd` to `fkadd --self`, so the `--self` flag isn't necessary (except for commands like `fkclean` where it does make sense to have it).
Copy file name to clipboardExpand all lines: docs/about/social.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -33,7 +33,7 @@
33
33
34
34
---
35
35
36
-
This isn't really _our own YouTube_, it's the creator's personal channel and has unrelated stuff. Still, major release trailers will be here (and a trailer for V3 is work in progress).
36
+
The creator's personal channel*. Major release trailers will be here. (\*as such, unrelated stuff also hangs in there).
Copy file name to clipboardExpand all lines: docs/learn/cross-runtime-support.md
+7-7Lines changed: 7 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,18 +7,18 @@
7
7
8
8
While FuckingNode can be a very powerful automation tool if properly used, in the end it's just an executable that _automates_ tasks; it doesn't do much on its own. Thus, **features that aren't supported by a runtime itself, won't work with us**. (Adding "polyfills" or "glue fixes" is not discarded as an idea, but not planned short-term anyway).
9
9
10
-
You can run `compat` anytime from the CLI to see a table showing what works and what doesn't. **NodeJS is the only environment with 100% platform support.** As of version 3.3.1, that table looks like this:
10
+
You can run `compat` anytime from the CLI to see a table showing what works and what doesn't. **NodeJS is the only environment with 100% platform support.** As of version 4.0.0, that table looks like this:
Reasons for not supporting a feature are the following.
@@ -33,9 +33,9 @@ In all these runtimes, the kind of cleanup commands we'd use (`prune`, `dedupe`.
33
33
34
34
FuckingNode itself is written in Deno, thus we're disallowed by the runtime from cleaning its cache. While a "gluefix" exists, it doesn't work most of the time.
35
35
36
-
## No Cargo & Go support for release
36
+
## No Golang support for release
37
37
38
-
We might add them in the future, for now they're not supported because they're harder to implement (as more steps are required).
38
+
We might add it in the future, for now it's not supported because it're harder to implement (as more steps are required).
39
39
40
40
## Partial Cargo & Go support for commit
41
41
@@ -49,6 +49,6 @@ Golang _do_ support it but doesn't support the Recommended Community Standards p
49
49
50
50
There's a single package manager for these platforms, `migrate` is useless.
51
51
52
-
## No audit support anywhere non NodeJS
52
+
## No audit support for Deno, Cargo, or Go
53
53
54
-
Deno and Bun do not offer an `audit` command, neither do Go nor Cargo.
54
+
Neither Deno, nor Golang, nor Cargo, offer an `audit` command.
> `fuckingnode build <project>`, or `fkbuild <project>`
4
+
5
+
The `build` command in FuckingNode allows you to run all the commands of your project's building / compilation process (which are usually several) from a single command. It'll show progress, and halt execution if any command fails. It makes your workflow slightly faster since it's just one command that you have to run.
6
+
7
+
## Usage
8
+
9
+
To build your project, first define all the commands that should run in your `fknode.yaml` by setting the `buildCmd` key. This uses a "peculiar" notation; it's a single string where commands are separated by the `^` character:
10
+
11
+
```yaml
12
+
# imagine a 3 step build process:
13
+
# some prerelease code, then locally building your project, then deploying it
14
+
buildCmd: "node prerelease.js^npm run build^cd dist^vercel --prod"
15
+
```
16
+
17
+
The above example would result in this:
18
+
19
+
```bash
20
+
node prerelease.js
21
+
npm run build
22
+
cd dist
23
+
vercel --prod
24
+
```
25
+
26
+
Once defined, just run `build` and it'll build the project in the current working directory. You can also explicitly specify a path.
27
+
28
+
```bash
29
+
fuckingnode build # builds here
30
+
fuckingnode build ./projects/some-project # builds there
31
+
```
32
+
33
+
---
34
+
35
+
A cool thing is that you can link it to `release` (feature explained in the [next page](./release.md)), by setting `buildForRelease` to `true` in your `fknode.yaml` (see [fknode.yaml](./fknode-yaml.md#buildforrelease)). If set, these commands will auto run whenever you run the `release` command, so we automatically build your project before releasing it.
36
+
37
+
---
38
+
39
+
There's nothing more to configure. It's a relatively simple automation.
40
+
41
+
### What to expect
42
+
43
+
Progress with all commands will be printed step by step.
44
+
45
+
```bash
46
+
✔ There we go, time to build <project name here>
47
+
Running command 1/5
48
+
*output of 1st command*
49
+
Done!
50
+
Running command 2/5
51
+
*output of 2nd command*
52
+
Done!
53
+
(...)
54
+
Running command 5/5
55
+
*output of 5th command*
56
+
Done!
57
+
✅ That worked out! Your project should be built now.
58
+
```
59
+
60
+
If an error happened, it'd show it and stop execution.
`message` is obvious and mandatory, `branch` is optional is the branch to commit to. If not given, the branch you were currently on will be used. `--push` is optional too, and if passed, the commit will be pushed to the remote repository.
15
+
`message` and `files` are obvious and mandatory. Anything after the message (which must be quoted) is considered a file until a `--`flag appears. All flags are optional.
16
+
17
+
Flag `--branch [branch-name]` indicates the branch to commit to. If not given, the branch you're currently on will be used. `--push` can be passed to push the commit to the remote repository. `--keep-staged` can be passed to include files you had in the stage area before running this command (if not passed, the default behavior is to unstage all files, then stage the ones you provide to the command).
16
18
17
19
### Configuring the task to be executed
18
20
19
-
As said, you can add a task (for example your test suite) and have it run before committing. The commit will only be made if this task succeeds (exits with code 0). Specify the task by setting the `commitCmd` key in your `fknode.yaml` to a script to be executed (see [fknode.yaml docs](fknode-yaml.md)).
21
+
As said, you can add a task (e.g., your test suite) and have it run before committing. The commit will only be made if this task succeeds (exits with code 0). Specify the task by setting the `commitCmd` key in your `fknode.yaml` to a script to be executed (see [fknode.yaml docs](fknode-yaml.md)).
@@ -29,17 +31,20 @@ If absent, no custom task will be executed.
29
31
You'll see a confirmation like this one, showing what will be made:
30
32
31
33
```txt
32
-
🚨 Heads up! We're about to take the following actions:
33
-
Run deno task test
34
-
If everything above went alright, commit 0 file(s) to branch v3 with message "test"
34
+
✅ Staged all files for commit (4).
35
+
❓ Heads up! We're about to take the following actions:
36
+
37
+
Run deno task precommit
38
+
If everything above went alright, commit 4 files to branch v4 with message "minor fixes"
39
+
40
+
- all of this at @zakahacecosas/fuckingnode@4.0.0 C:\Users\Zaka\projects\FuckingNode
35
41
36
-
- all of this at @zakahacecosas/fuckingnode@3.2.0 C:\Users\Zaka\FuckingNode
37
42
Confirm? [y/N]
38
43
```
39
44
40
45
If you input `y`, all tasks will run, and unless they fail, a commit will be made (and pushed if enabled, which would have shown up in the shown above list).
41
46
42
-
No files are added to Git, so just as you would normally do, run `git add (whatever)` before running our commit command.
47
+
You can also run the command with the `--yes` flag to skip this - though we don't really recommend it.
0 commit comments