moonrepo / moon Goto Github PK

Is your feature request related to a problem? Please describe.

It's not convenient to run a code block in tasks currently, which is quite common if we want moon to be "language agnostic and easily pluggable in the future."

Describe the solution you'd like

Add running code block support for tasks, like

tasks:
    build:
           shell: bash    # It will be better if we can change to other shells, support syntax like `['bash', '-c']` or `bash -c`
           load-dotenv: true   # load a `.env` file automatically for the following code block
           run: |    # Writing multi-line commands for better readability
                 npm ci
                 npm run build
                 echo 'Done'

REF: https://docs.github.com/en/github-ae@latest/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun

Describe alternatives you've considered

Additional context

Describe the bug

Right now errors go to stderr, while everything else goes to stdout.

Steps to reproduce

N/A

Expected behavior

Everything goes to stderr, so it can be piped together.

Screenshots

Environment

Additional context

• #228
• #207
• Support project aliases? Look into ways to use a package.json name.
  • Support / and @ in IDs?
• Infer tasks.*.type based on the command. Do our best to detect "system".
• Refactor hash cache to use .tar files instead of copying entire folders.
• Update default tool versions.

Is your feature request related to a problem? Please describe.

Nope

Describe the solution you'd like

YAML supports reusing values within a document through features known as anchors and aliases. It looks something like the following:

tasks:
    build: &webpack_shared
        command: webpack
        args: build
        inputs:
            - 'src/**/*'
    start:
        <<: *webpack_shared
        args: start

It would be nice if our config files supported this syntax.

Describe alternatives you've considered

Additional context

Work has started here https://github.com/moonrepo/moon/tree/05-yaml-ref but seems to be blocked by serde_yaml: dtolnay/serde-yaml#245

Is your feature request related to a problem? Please describe.

As per the description of moon itself:

The primary focus of moon is a build system, and for it to operate in any capacity, it requires tasks to run. In moon, a task is an npm binary or system command that is ran as a child process within the context of a project (is the current working directory). Tasks are defined per project with project.yml, or inherited by all projects with .moon/project.yml.

It seems moon however doesn't have a concept of root level tasks, only project level? Can the root be set as a project, the docs don't seem to suggest so as I guess you'd also need a project.yml there?

Describe the solution you'd like

The ability to define tasks in the workspace.yml such as running package.json tasks or passing local scripts

Describe alternatives you've considered

Just run them as package manager tasks or shell scripts - but possibly don't benefit from moons features with these tasks.

• Only load project configs (package.json, tsconfig.json) once instead of re-reading the file constantly. This will require sharing the struct across threads using Arc<RwLock<OnceCell>>>.
• Verify if we can use YAML references. Support is dependent on serde_yaml.
• #147
• Rework config crate error handling. Instead of doing figment -> validator, we should do the reverse.
• Cache VCS (git) commands.
• Detect VCS settings during moon init.
• Increase code coverage and add more integration tests.

Is your feature request related to a problem? Please describe.

No, new feature.

Describe the solution you'd like

Currently the task's deps field accepts a list of targets, in the format of "project:task". While this works, it can be quite tedious to explicitly list out all project dependencies for every task. To work around this, the following values can be used instead of project names, to auto-fill multiple values.

• ^:<task> - Will mark all project dependencies (dependsOn in project.yml) as task deps, if they have a task with the name <task>.

tasks:
  build:
    command: 'webpack'
    args:
      - 'bundle'
    deps:
      - '^:build'
      # Instead of 
      - 'foo:build'
      - 'bar:build'
      - 'baz:build'

• ~:<task> - Will reference a task named <task> within itself/the owning project. This is a shortcut for using the own project's name in deps.

tasks:
  build:
    command: 'jest'
    deps:
      - '~:build'
      # Instead of 
      - 'self:build'

Describe alternatives you've considered

N/A

Additional context

Is your feature request related to a problem? Please describe.

Nope

Describe the solution you'd like

Tasks can define dependencies (https://moonrepo.dev/docs/config/project#deps), which are other tasks that must be ran before this task can be run. While this currently works, these dependencies run in parallel, where as sometimes you may want them to run in serial. For example, given the following task:

tasks:
  release:
    command: '...'
    deps:
      - '~:clean'
      - '~:build'
      - '~:check'

On the surface it seems viable, but in actuality, the clean step must be finished before the build step, which also must be finished before the check step. What we want is:

clean -> build -> check -> release

Instead of:

clean | 
build | -> release
check |

This problem can be solved with the deps field and creating a manual chain, but this can be rather cumbersome, and makes it quite hard to reuse these tasks in other dependency chains.

tasks:
  clean:
    command: '...'
  build:
    command: '...'
    deps: ['~:clean']
  check:
    command: '...'
    deps: ['~:build']
  release:
    command: '...'
    deps: ['~:check']

Instead, we can simply toggle between parallel and serial via an option on the task, like so:

tasks:
  release:
    command: '...'
    deps:
      - '~:clean'
      - '~:build'
      - '~:check'
    options:
      serialDeps: true
      # or
      runDepsInSerial: true

Describe alternatives you've considered

N/A

Additional context

Describe the bug

If a file was deleted and was not committed yet, it will crash git when passed to git hash-object. For example, passing:

packages/runtime/tests/foo.test.ts > git hash-object --stdin-paths

Results in:

Process git failed with a 128 exit code.
fatal: Cannot open 'packages/runtime/tests/foo.test.ts': No such file or directory

Steps to reproduce

• Delete a file that is within git's history.
• Keep the deleted file in your staging area, do not commit it.
• Run a task that has the file in its inputs list.

Expected behavior

We shouldn't pass deleted files to git hash-object.

Screenshots

Environment

Additional context

Is your feature request related to a problem? Please describe.

No

Describe the solution you'd like

The init command is pretty bare bones right now, it simply creates the .moon folder and default configs. Here are some ways to improve it:

• Automatically infer the projects list via package.json workspaces. This is only possible in an existing repo, so hide behind a flag like --inheritExistingProjects.
• Automatically infer the node.version if there's an nvmrc or something similar.
• Automatically infer the node.packageManager if there's a packageManager field in package.json, or similar configs like .yarnrc.

Describe alternatives you've considered

Additional context

Is your feature request related to a problem? Please describe.

Feature.

Describe the solution you'd like

We should use tokio as much as possible and embrace async/await.

Describe alternatives you've considered

Additional context

• Add $projectType, $taskType, and $language tokens.
• Add actionRunner.implicitInputs to .moon/workspace.yml. These inputs are then inherited by all tasks automatically.
• Add --type and --language filters to moon query projects.
• Add moon dep-graph command.
• Expand docs with FAQs

Investigate

• Refactor our project graph to pass around Project references instead of cloning.

The project.yml is rather straight forward, it configures the project. However, this name is very generic, and is also used by other tooling, such as:

• xcodegen - https://github.com/yonaskolb/XcodeGen
• DigitalOcean - https://docs.digitalocean.com/products/functions/reference/project-configuration/
• Frontastic - https://docs.frontastic.cloud/v1.1/docs/projectyml

The risk of collision is a non-zero amount. We should potentially rename it?

My only suggestion is moon.yml, which would align a bit nicer with .moon/*.yml files.

Is your feature request related to a problem? Please describe.

No.

Describe the solution you'd like

Right now our toolchain assumes a single node version, which is great for teams and companies. But for open source projects, we need to test multiple node versions, which currently isn't possible.

To support this, a CI environment can set MOON_NODE_VERSION to override the configured node version. We should probably do the same for npm/yarn/pnpm.

Describe alternatives you've considered

Additional context

Describe the bug

$ moon --log debug setup
...
[debug 12:03:15] moon:toolchain:node Tool has not been downloaded, attempting

 ERROR  Internet connection required, unable to download and install tools.

Steps to reproduce

1. git init
2. moon init
3. moon --log debug setup

Expected behavior

Resource should be able to be downloaded

Environment

System:
    OS: Windows 10 10.0.19044
    CPU: (4) x64 Intel(R) Xeon(R) Gold 6148 CPU @ 2.40GHz
    Memory: 24.10 GB / 32.00 GB
  Binaries:
    Node: 16.15.0
    Yarn: 1.22.19
    npm: 8.12.0
  Managers:
    Cargo: 1.61.0
  Utilities:
    Git: 2.36.1.
  IDEs:
    VSCode: 1.67.1
  Languages:
    Rust: 1.61.0

Additional context

I suspect a corporate proxy problem, is there a switch around self signed certs comparable to NODE_TLS_REJECT_UNAUTHORIZED?

• #229
• Add Linux arm64 support
• Add a CI report/manifest
• Add affected support to moon query projects
• Make typescript setting optional
• Integrate Astro build
• Investigate a GitHub bot/app/action
• Finalize eslint/jest/etc packages

thread 'tokio-runtime-worker' panicked at 'called Result::unwrap() on an Err value: Error { kind: InvalidData, message: "stream did not contain valid UTF-8" }', crates/lang-node/src/node.rs:46:50
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

Describe the bug

When running moon query project if a task in a project has envFile true but there is no .env (e.g. in a CI) it causes the whole command to fail.

Steps to reproduce

1. Set a task options to envFile: true
2. Run moon query project

Expected behaviour

The query should not fail, instead maybe a warning?

Screenshots
No screenshot, but output:

Error: Command failed: yarn moon query projects
 ERROR 
Failed to parse env file ~/github/hub/services/api-auth/.env: No such file or directory (os error 2)

Additional context

The reason this is coming about is we have a CI task where you can pass the name of the task you want to run, internally a few scripts then I can get the workspace object:

export async function getWorkspace(workspace: string) {
  const buffer = await getExec('yarn moon query projects');
  const projectList = JSON.parse(buffer.stdout) as Record<string, any>;
  return projectList.projects.find((p: Record<string, any>) => p.id === workspace);
}

From this I can then get the root of the project - maybe this isn't a bug but a different command.

Describe the bug

running moon just flashes a shell windows which closes directly (probably opens/ runs in new shell and closes immediately after). i recorded the issue with a screen recorder, but the flashing cmd window does not show

Steps to reproduce

install under windows with npm install -g @moonrepo/cli

Screenshots

Environment

os: windows 11
shell: PowerShell 7.2.5
moon path: C:\Users\...\AppData\Roaming\npm\moon.CMD

 System:
    OS: Windows 10 10.0.22000
    CPU: (12) x64 AMD Ryzen 5 4600H with Radeon Graphics
    Memory: 3.81 GB / 15.37 GB
  Binaries:
    Node: 16.3.0 - C:\Program Files\nodejs\node.EXE
    npm: 7.15.1 - C:\Program Files\nodejs\npm.CMD
  Managers:
    Cargo: 1.61.0 - ~\.cargo\bin\cargo.EXE
    pip3: 19.2.3 - ~\AppData\Local\Programs\Python\Python37-32\Scripts\pip3.EXE
    RubyGems: 3.2.32 - C:\Program Files\Ruby30-x64\bin\gem.CMD
  Utilities:
    Git: 2.32.0.
  Virtualization:
    Docker: 20.10.14 - C:\Program Files\Docker\Docker\resources\bin\docker.EXE
  SDKs:
    Windows SDK:
      AllowDevelopmentWithoutDevLicense: Enabled
      AllowAllTrustedApps: Enabled
      Versions: 10.0.18362.0, 10.0.19041.0
  IDEs:
    VSCode: 1.68.1 - C:\Users\aschu\AppData\Local\Programs\Microsoft VS Code\bin\code.CMD
    Visual Studio: 16.10.31424.327 (Visual Studio Community 2019)
  Languages:
    Bash: 5.0.17 - C:\WINDOWS\system32\bash.EXE
    Go: 1.16.6 - C:\Program Files\Go\bin\go.EXE
    Java: 18.0.1.1
    Perl: 5.32.1 - C:\Pearl\perl\bin\perl.EXE
    Python: 3.7.7
    Ruby: 3.0.3 - C:\Program Files\Ruby30-x64\bin\ruby.EXE
    Rust: 1.61.0
  Databases:
    PostgreSQL: 14.1 - C:\Program Files\PostgreSQL\14\bin\postgres.EXE
  Browsers:
    Edge: Spartan (44.22000.120.0), Chromium (103.0.1264.44), ChromiumDev (None)
    Internet Explorer: 11.0.22000.120

Additional context

running moon within package.json (npm run moon ...) works and install moon in ubuntu via wsl under windows works as well.

Is your feature request related to a problem? Please describe.

No, new feature.

Describe the solution you'd like

Currently the dep-graph and project-graph commands output DOT that can be piped to a file. Instead we should open a browser window that renders an interactive project graph will full data.

The DOT output can be enabled with a --dot arg.

Describe alternatives you've considered

N/A

Additional context

Is your feature request related to a problem? Please describe.

No.

Describe the solution you'd like

We should run the node install action during moon setup, so that node modules are installed, engines are synced, etc.

Otherwise, a task needs to be ran for these to happen.

Describe alternatives you've considered

Additional context

Describe the bug

I was giving moon a test-drive. It worked until I tried to execute a task (with eslint).

Steps to reproduce

1. Clone moonrepo/examples

2. Switch from npm to pnpm in .moon/workspace.yml

3. In project root: echo "strict-peer-dependencies=false" > .npmrc (for sanity)

4. Create pnpm-workspace.yaml file with these contents:

   packages:
     - "apps/*"
     - "packages/*"
   

5. Install pnpm i

6. Run moon run mjs-package:lint

Expected behavior

eslint will run

Screenshots

Here is the console output:

❯ moon run mjs-package:lint
▪▪▪▪ mjs-package:lint
eslint --ext .ts,.tsx,.cts,.mts,.js,.jsx,.cjs,.mjs --fix --report-unused-disable-directives --no-error-on-unmatched-pattern --exit-on-fatal-error --ignore-path ../../.eslintignore . (in ./packages/mjs-package)
/Users/gossi/code/playground/monorepo-examples/node_modules/.bin/eslint:2
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
          ^^^^^^^

SyntaxError: missing ) after argument list
    at Object.compileFunction (node:vm:352:18)
    at wrapSafe (node:internal/modules/cjs/loader:1033:15)
    at Module._compile (node:internal/modules/cjs/loader:1069:27)
    at Module._extensions..js (node:internal/modules/cjs/loader:1159:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Module._load (node:internal/modules/cjs/loader:827:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:77:12)
    at node:internal/main/run_main_module:17:47

Node.js v18.0.0
▪▪▪▪ mjs-package:lint (297ms)

 ERROR  Process ~/.moon/tools/node/18.0.0/bin/node failed with a 1 exit code.

PS. This is a similar problem with other tools as well (not only eslint - I also tried ember-template-lint, bcz of the project I had at hand).

Environment

Command npx envinfo failed to execute 😅

I tried moon v0.5 and v0.6 - both failed.

I have a monorepo with both apps and packages similar to the examples repo. The apps are deployed using vercel and the package's release is managed by changesets. I am updating my release GitHub to release the packages, is there a way to only build just the packages? Will the task runner accept a glob for tasks? yarn moon {packages/*}:build

PR for reference

i would like to be able to use execute any shell command in a selectable shell.
most users have several cli utilities install that are only available in a certain shell with a profile)

shell: powershell
os: win 11
moon: 0.8.0

.moon/project.yml

tasks:
  clean:
    command: 'rimraf'
    type: 'system'
    args:
    - ' dist'

current error message

  $ moon run types:clean
▪▪▪▪ types:clean

 ERROR  Process failure for rimraf: program not found

rimraf is installed globally with npm

also why cant the command value be a 'sentence' (string with whitespaces), to write the full command of something?
if you need any further information please let me know.

When running moon run :build I get:

Process failure for ......\node_modules@moonrepo\cli\moon.exe: The system cannot find the path specified. (os error 3)

Everything is installed and setup through moon sync and moon setup.

Is your feature request related to a problem? Please describe.

When working with TypeScript monorepo projects to improve import paths we can use path mapping to improve the import paths within the project using the referenced package. It is frustrating to have to manually apply these project path mappings.

Describe the solution you'd like

When the tsconfig references sync happens, the compilerOptions path mapping is also synced.

Describe alternatives you've considered

NX nwrl tooling does this as part of its project linking. Otherwise, it has to be manually configured.

Additional context
How the tsconfig could be configured

{
  "extends": "../tsconfig.options.json",
  "compilerOptions": {
    "rootDir": "./src",
    "paths": {
      "@namespace/package-a": ["../packageA/src/index.ts"],
      "@namespace/package-a/*": ["../packageA/src/*"]
    }
  },
  "exclude": ["dist"],
  "include": ["./src"],
  "references": [
    {
      "path": "../packageA"
    }
  ]
}

Is your feature request related to a problem? Please describe.

Nope

Describe the solution you'd like

A great quote by Jamie Kyle, "If your developer tool is not running in the editor, it’s running too late". https://twitter.com/buildsghost/status/1537133064454742016

And I agree. A lot of developers are heavily invested in their editor/IDE, and prefer to not tab to their terminal to verify things aren't broken. This includes running the linter, tests, builds, etc.

To that end, we should support an official moon VS Code extension (with potential for other editors in the future) that provides the following features:

• Validates config files (.moon/workspace.yml, .moon/project.yml, and project.yml) based on the $schema field and the associated JSON Schema under the hood. VSC does not support this out of the box.
• Introduce a sidebar panel (similar to "npm scripts") that lists all projects and their associated tasks in the moon workspace. For each project or row, there will be action buttons that will run the moon binary within VSC's terminal.

Panel

Here's a rudimentary outline of the panel using ASCII art.

Applications
v [js] project-a                 [$] [i]
    build webpack                [*] [>]
    format prettier
    lint eslint
    test jest
    typecheck tsc
> [js] project-b                 [$] [i]
Libraries
> [ts] project-c                 [$] [i]

Functionality:

• Top-level lists projects in alphabetical order, grouped by project type. This is based on the type field in project.yml.
• Project row:
  • Displays the project language as icon on the far left (JS, TS, etc). This is based on the language field in project.yml.
  • Displays the project ID after the type on the left.
  • When hovered or expanded, displays an "information" button on the right that runs moon project <id> in the terminal. Also displays a "view project" button that opens the project.yml file, or a package.json file.
  • Can be expanded or collapsed by clicking the arrow on the left.
  • Lists out all tasks within the project as nested rows, in alphabetical order.
• Task row:
  • Displays the task ID on the left.
  • Displays the underlying command to be ran after the ID. This text uses a muted color.
  • When hovered, displays "debug" and "run" buttons on the right that runs moon run <target> in the terminal. Debug mode will enable the Node.js profiler once that functionality lands.
• When jumping between files in the editor, the expanded project should reflect which project the file belongs to. This works in a similar fashion to VSCs "expand file tree when jumping around files" feature.

Nice to haves:

• Shortcuts/hotkeys for running the tasks. Not sure what this would look like.
• Adding the "run task" functionality to the command palette.

Describe alternatives you've considered

N/A

Additional context

N/A

When running moonrepo from the root directory all the projects that have folder's names capitalized are not detected.

Dependency graph with projects names capitalized

and without

Best,
Nikola.

Hey,

I was evaluating a couple of monorepo tools (including moon). Even though not everything worked yet for me (#195) (or I wasn't able to try out everything), I was able to grasp the idea of it. I wanted to share some feedback how that feels to me.

moon binary and volta

Let's start: I'm a volta user myself, and I realized, moon is kinda doing the same/similar job, which is cool. Guess what, I installed moon through volta and have it in devDeps of my workspace root package.json. So, by using two times a rust implementation, I think I actually call moon through pnpm.

moon -> volta -> finds executable moon in node modules bin -> calls moon through pnpm.

I'm not exactly sure, if this is how it ends up being called but from my understanding. So, the idea of calling moon as global bin and avoid the node runtime overhead was "killed" by that. I think it would be different if I don't have it installed as devDep of my workspace (but still use volta to install and run it). Perhaps some investigation or install notes when using volta?

projectID and taskID

That greeted me on the introduction page:

Reduced scripts confusion - package.json scripts can become unwieldy, very quickly. No more duplicating the same script into every package, or reverse-engineering which root scripts to use. With moon, all you need to know is the project ID, and a task ID.

my first thought: Why does it have to be an ID? (I had uuid or similar in mind here). I already know the name of my packages and the tasks at hand o_O

projects != projects

All projects in a monorepo (should) have distinct names, the name from package.json - but moon wants another name for it... why? Like, it already has one, why not read from package.json? Feels like, package.json is ignored here.

More divergance from package.json: Not reading dependencies

So, I tried the project graph, but everything was only depending from the workspace itself. I checked my dependencies in package.json but they weren't visible in the graph. I figured I had to manually set them in project.yml. This information is already present through workspace config + package.json, why should I duplicate my information here? The single-source of truth has become a multi-source?

Even more divergance from package.json? No scripts?

Classical scripts do not exist in a moonrepo. I do get it, I understand it. It has to do with the underlying tools and the promised speed by circumventing the node runtime. Also BUT they are far off from package.json. Just another point where it feels like moon is ignoring package.json.

Well, these are my feelings of a first-hand experience with moon. I think it sounds harsher than it is. Actually, I really like the idea behind it and it could use a more tangible access to the existing behaviors, hence this is the reason I left this feedback here 😊

So, a little FWIW that would please me:

(1) Use package.json (and workspace) as much as possible for name and dependencies - I don't want to duplicate that information manually

(2) Try to use scripts from package.json? I see my monorepo (and its individual packages) more like hexagonal architecture. moon is one input into my monorepo, but I think it positions itself as the only input here. I see the technical challenge here for sure. But if I would have this kind of script:

"scripts": {
  "lint": "eslint ."
}

I'd expect moon to be able to execute it - ie. taking the command and executing it itself. Or through package manager; maybe with a warning that this way it runs slower?

I hope this feedback helps. I'll keep having an eye on moon :)

Cool things to look forward to!

• Support a list of globs in .moon/workspace.yml projects instead of a map. This will automatically find projects when moon is ran.
• Move the project.yml project.type field to the root of the document, so that it can be defined by itself.
• Add a language setting to project.yml.
• Improve handling of colored output. It seems to work well in yarn, but has issues in npm. Unsure about pnpm.
• Better code coverage and more integration tests.

• Automatically create a tsconfig.json when syncing project references and the file is missing.
• Add Chrome profiling to spawned Node.js processes.
• Add a @group() token that copies file group values as-is.
• Start on a moon query CLI command.

• TypeScript - Add a routeOutDirToCache setting.
• TypeScript - Add a syncDependenciesAsPaths setting: #319
• Support project-level tool version overrides (workspace.node.version).
• Add runner.implicitDeps.
• Support file extensions (like .tpl or .tera) for template files.

Is your feature request related to a problem? Please describe.

Nope

Describe the solution you'd like

Just some ideas for improving the generator and templates.

• Support frontmatter in each template file: https://www.hygen.io/docs/templates#frontmatter
• When a write conflict with a JSON/YAML file, add a prompt option for merging the 2 files.
• Support a Tera file extension (like .tpl) that will be removed during write. This should enable better syntax highlighting.
• Add more configurable options for variables: max length, between, etc.
• Add object form for enum values, so that custom labels can be provided.
• The template files that are copied/created can be filtered. Maybe with an --include or --exclude.
• Dynamic destination paths, e.g., packages/{{ name | kebab_case }}.

Describe alternatives you've considered

N/A

Additional context

Is your feature request related to a problem? Please describe.

No.

Describe the solution you'd like

Currently the setup/teardown commands display no output while they are running, or when they finish.

Let's add progress spinners that continuously run until the future has resolved.

Describe alternatives you've considered

N/A

Additional context

Use indicatif https://docs.rs/indicatif/latest/indicatif/index.html

Is your feature request related to a problem? Please describe.

Nope

Describe the solution you'd like

We should apple #[inline] to our functions (when applicable) for performance improvements. https://nnethercote.github.io/perf-book/inlining.html

Describe alternatives you've considered

Additional context

I've never used inlining in Rust before, so I'm not sure what "best practices" are. I did notice that Rome is using it heavily: https://github.com/rome/tools

Is your feature request related to a problem? Please describe.

No

Describe the solution you'd like

Use "M◐◑N" or something similar when the moon name is used in CLI output.

Describe alternatives you've considered

N/A

Additional context

Is your feature request related to a problem? Please describe.

There are 2 huge issues with serde_json, they are:

• It writes None fields as null. We should always skip none options, and avoid adding this to every field: https://github.com/milesj/moon/blob/master/crates/config/src/package.rs#L14
• The field order that is written is different than the order when deserializing. We need to keep it the same to avoid large diffs.

Describe the solution you'd like

Described above.

Describe alternatives you've considered

Additional context

Is your feature request related to a problem? Please describe.

No

Describe the solution you'd like

Right now our release scripts are a mix of bash and js: https://github.com/moonrepo/moon/tree/master/scripts/release

Let's migrate the js ones to bash, as they're not doing anything complicated, and to keep things consistent. This also has the added benefit of not having to install Node.js or yarn install in CI.

Describe alternatives you've considered

Additional context

Small roadmap but they're all large features!

• Add template generator / scaffolding
• Implement project graph implicit dependency scanning
• Integrate GitHub action for run reports
• Avoid caching and hashing in Docker

• Add an envFile option to tasks.
• Add an "is long running" option to tasks.
• Add more output styles.
• Update moon run to support multiple targets.
• Add moon clean and other utils for cleaning up stale cache.
• TS v.4.8 compatibility
• Rust v1.63

• Add type to dependsOn, to differentiate between development and production deps.
• Support different dependency version types: workspace:*, link:, file:, *, etc.
• Support env vars as task inputs.
• Add a cache option to tasks.
• Handle all pnpm edge cases (different linker patterns).

Internals

• Clean up our fixtures usage/utils.

Breaking

• Rename tasks[].type? Maybe platform? Or runtime?

When using moonrepo with workspaces the folders inside the main project folder also get detected as projects. Such folders include .git, etc.

projects:
    - "app/**"

This is the logfile

✔ Successfully synced 22 projects
pass SetupToolchain (skipped)
pass SyncSystemProject(playform) (0s)
pass SyncSystemProject(info) (0s)
pass SyncSystemProject(objects) (0s)
pass SyncSystemProject(pages) (0s)
pass SyncSystemProject(remotes) (0s)
pass SyncSystemProject(pack) (0s)
pass SyncSystemProject(public) (0s)
pass SyncSystemProject(origin) (0s)
pass SyncSystemProject(workflows) (0s)
pass SyncNodeProject(blank-web-starter) (skipped)
pass SyncSystemProject(scripts) (0s)
pass SyncSystemProject(tags) (0s)
pass SyncSystemProject(refs) (0s)
pass SyncSystemProject(git) (0s)
pass SyncSystemProject(styles) (0s)
pass SyncSystemProject(layouts) (0s)
pass SyncSystemProject(logs) (0s)
pass SyncSystemProject(heads) (0s)
pass SyncSystemProject(app) (0s)
pass SyncSystemProject(src) (0s)
pass SyncSystemProject(hooks) (0s)
pass SyncSystemProject(github) (0s)

When I first start building moon, I separated the command and args settings for the following reasons:

• The command is used heavily for lookups and child process execution. Having a simple string was easiest.
• The args were initially a list of strings (supporting a string itself was added later), as iterating through and processing them was also easiest.

But now that moon is rather stable, and I have personally started using it on external projects (dogfooding, woo), as well as other developers, it's become quite apparent that having these be separate settings is rather annoying. Because of this, I'm proposing merging command and args into a single setting, command, which will include the command/binary name and all args.

This new setting can be written with a string or a list of strings, but the binary itself must be the first item.

# Before
tasks:
  clean:
    command: 'rm'
    args: '-rf /'
    type: 'system'
  build:
    command: 'webpack'
    args:
      - 'build'
      - '--mode'
      - 'production'
    options:
      cache: true

# After
tasks:
  clean:
    command: 'rm -rf /'
    type: 'system'
  build:
    command:
      - 'webpack'
      - 'build'
      - '--mode'
      - 'production'
    options:
      cache: true

What about task merging?

When inheriting tasks from the global workspace, tasks of the same name are merged (https://moonrepo.dev/docs/concepts/task#merge-strategies). How will this be affected?

Internally, we have TaskConfig and Task structs. The combining of command/args into a new field will only occur in TaskConfig, while the separation of command/args will still persist for Task. And since the merging happens in the Task struct, this will continue to work without any changes.

What about token substitution?

Tokens, like merging (above), happen on the Task struct, and should continue to work without any changes.

Potential issues

• Values placed before the "command to run" will cause issues. If anything, it will just crash the process and force the developer to remedy the issue.

This release will focus heavily on Node.js interoperability, primarily around package.json integration.

• Add a special noop task (necessary for other features).
• Add a moon migrate from-package-json command that will:
  • Migrate package.json scripts to project.yml tasks.
  • Migrate package.json dependencies (for local workspace linked packages) to project.yml dependsOn.
• Add a moon sync command that syncs the entire repository to a healthy state.
• Add a node.inferTasksFromPackageScripts setting that will infer and create project.yml tasks from package.json scripts.

• Add moon docker scaffold command to create the repo skeleton for COPY.
• Add moon docker prune command to prune the repo when in a docker container/image.
• Implement event emitter in workspace and action runner.
• Update toolchain to support arbitrary tool + version combos. This unlocks different versions per project.
• Support template file frontmatter.

• Add moon check command
• Use versions from lockfile instead of package.json for hashing
• Split SetupToolchain action to be language/platform specific
• Error if an output is defined but it was not created
• Add types package
• Add astro command checks
• Rename actionRunner to runner

Is your feature request related to a problem? Please describe.

No

Describe the solution you'd like

Right now to run a build/lint/etc you have to type moon run <project>:build. While this isn't too verbose, we should also support shortcuts like moon build <project>, moon lint ..., moon format ..., etc.

Describe alternatives you've considered

Additional context

In one project moon.yml the dev task has the envFile property set to true, also local: true

When running the build task in our CI, it fails to try to load a .env file even though this is not set on the task

Steps to reproduce

run yarn moon run api-server:build in the CI pipeline

output:

Failed to parse env file ~/work/repo/services/api-server/.env: No such file or directory (os error 2)

$schema: 'https://moonrepo.dev/schemas/global-project.json'

type: 'application'
language: 'typescript'

tasks:
  dev:
    local: true
    options:
      envFile: true
    command: 'yarn'
    args: 'run start'
    deps:
      - 'api-server:prestart'
    inputs:
      - 'src/**/*'
      - 'tsconfig.json'
      - 'package.json'
  prestart:
    options:
      cache: false
    command: 'yarn'
    args: 'run prestart'
    inputs:
      - 'src/**/*'
      - 'tsconfig.json'
      - 'package.json'
    outputs:
      - 'dist'
  build:
    command: 'yarn'
    args: 'run build'
    inputs:
      - 'src/**/*'
      - 'tsconfig.json'
      - 'package.json'
    outputs:
      - 'dist'

Expected behavior

Build should run without .env file present

Environment

GitHub Actions

Describe the bug

When I run vue-tsc as a task from moon, it does not output error details.

Steps to reproduce

1. Clone moonrepo/examples
2. In project root npm i
3. Edit apps/vue-vite-app/src/App.vue

- import { RouterLink, RouterView } from 'vue-router';
+ import { RouterLin, RouterView } from 'vue-router';

Expected behavior

Run npx -w apps/vue-vite-app vue-tsc --noEmit --project tsconfig.vitest.json --composite false

Normally, vue-tsc error output looks like this.

however...

Run npm run moon r vue-vite-app:typecheck

Environment

• moon v0.9.0
• npm v8.11.0
• node v16.16.0
• macOS 12.4 (Intel)

Is your feature request related to a problem? Please describe.

Nope

Describe the solution you'd like

For situations where we unwrap() and may panic, we should annotate with #[track_caller].

https://blog.rust-lang.org/2020/08/27/Rust-1.46.0.html#track_caller

Describe alternatives you've considered

Additional context