Does deno support monorepo?

[allangomessl]

Does it support monorepo?
if yes, where I can find a good sample project?

[satyarohith]

Can you elaborate on what it means to support monorepo? :)

[puentesdiaz]

i think is this :
https://docs.npmjs.com/cli/v8/using-npm/workspaces

[utamori]

Go also supports monorepo.
https://go.googlesource.com/proposal/+/master/design/45713-workspace.md

[puentesdiaz]

At the end, Deno in 2022, support workspace?

[eric-burel]

The main need you have when running a monorepo is easily linking local packages one with another + running dependant tasks in the fastest topological order.
From a technical standpoint, that probably means being able to "hack" the URL system so that importing "foobar/mod.ts" is turned into "file://your-monorepo/foobar/mod.ts" when running the monorepo locally, and also have a task runner that support custom scripts (so running "deno build" instead of "package.json >scripts > npm run build"

[foo0110]

Does it support monorepo?
if yes, where I can find a good sample project?

@allangomessl you mean something similar to nx.dev? I am interested to know if there's any.

[theoparis]

Yeah I would also like to know if this is possible. I use pnpm/yarn workspaces feature a lot and I don't know if this exists in Deno.

[jupegarnica]

The question make no sense. Deno do not have a package concept.

Deno just runs a file (and all its dependencies), a module(file) than can depend on others modules locally or remotelly.

So to have a monorepo with deno code simply put all deno source in a folder.

To sum up: Yes , It works on monorepos :D

[airtonix]

No Sir, a monorepo is not merely a repo with everything dumped into it.

See my answer on stack overflow https://stackoverflow.com/a/72198790/454615

If you only have apps, then I'm sorry... but all you have is a repo of many apps.
A monorepo is a collection of packages that you can map a graph of dependencies between.

And like @eric-burel says #9126 (reply in thread):

The main need you have when running a monorepo is easily linking local packages one with another + running dependant tasks in the fastest topological order.
From a technical standpoint, that probably means being able to "hack" the URL system so that importing "foobar/mod.ts" is turned into "file://your-monorepo/foobar/mod.ts" when running the monorepo locally, and also have a task runner that support custom scripts (so running "deno build" instead of "package.json >scripts > npm run build"

and here in more detail

[yinonov]

seen nx.dev mentioned above so a followup question is the case where a nx workspace needs a pre-publish build step to get the package ready and nest in a dist folder. is this approach not applicable with deno?
isn't there a friendly migration process from node setup to deno?

[SimonVillage]

I believe that this implementation should be done by nx.dev rather than by deno. The right place for this discussion would be here: nrwl/nx#5823

[allangomessl]

I stopped using Deno for now, but right after this question I discovered import_map.json and I liked so much, flexible, easy and native.

Thank you guys.

[yinonov]

how does this relate? in what context are you using import maps?

[allangomessl]

we can organize our imports between modules, but I was unfortunate when I used the term monorepo in the question.

I think this is not idea of Deno, Deno is runtime and doesn't need to implement tools like monorepo.

[eric-burel]

I think I get the idea, and it is consistent with the fact that it's hard for VS code to support one config per folder. So instead a big import_map and Deno config at the root can help with having clean imports.

What bothers me is the publication step. How do you publish these packages independently on deno.land afterwards for instance? Can the reliance on a global import_map become problematic?

[eric-burel]

The accepted answer is definitely too simplistic to fully answer the question. Here are a few things I expect from a monorepo userwise, and how I picture it in Deno:

- the ability to interconnect local packages

In the Node world: there are multiple strategies in the wild. You can use a "file://" url, however this means having a way to rewrite the package.json during publication on NPM, or during publication of subdirectory on GitHub (the former is usually well supported but the later much less). They don't work well when sharing the code with multiple people. Better, you can use a specific "workspace:" syntax (PNPM-style for instance) as well, with the same approach for publishing (and same limitation when it comes to publishing a subrepo to GitHub). Finally some tools are simply able to detect that you want to load a local package with no specific syntax (yarn workspaces), which makes publication easier in my opinion, especially for the GitHub use case.

See our setup at Vulcan https://github.com/VulcanJS/vulcan-npm for a monorepo mixing apps and full-stack packages.

In Deno, the solution would rely on playing around with URL. Maybe setup a proxy server that intercepts all queries made by Deno, and can serve a local packages for those that match the current monorepo (I haven't yet dig the documentation far enough to tell if it's easy to setup or not).

Another approach could be supporting an array in "import_map.json", to try loading the package first from the local folder then from deno.land, syntax could be:

{
  "imports": {
    "@my-org/*": ["../*", "https://deno.land/my-org@latest/*"]
  }
}

- the ability to run scripts efficiently (build, test, lint and also custom scripts)

This one is solved by tools such as Lerna, Nx, Turborepo and friends, that compute a correct topological order to run the script, and can cache computations. This is an algorithmic problem mainly, however you have to correctly interface with the actual code. The current existing solutions expect a "package.json" to find the script,

For Deno, they would need slight adaptations to run "deno <script>" instead of looking for package.json scripts. For custom scripts it is more delicate as Deno provides no standard way to define them. I currently use "Just", maybe a makefile could be the standard? Either way you need to tell the script runner how to actually run each packages script.

- big bonus for Deno: TypeScript. Many monorepo seem to suffer from what I call the "double bundle" issue. They publish packages as standalone, which usually means translating TypeScript into JS.
ESM are a blessing as they produce sensical JavaScript code (see this beauty: https://github.com/jaydenseric/apollo-upload-client, I couldn't yet tell if those repo are auto-generated from a TS source or if the developer wrote the .esm manually, the codebase is quite readable and well documented either way) but there is still a bundling step, with issues such as how to properly generate .d.ts.map for vscode etc etc.

Deno TypeScript-first approach means your local packages can be TypeScript only. We will probably use this approach in a Node environment too for Devographics (Devographics/Monorepo#105), with packages written in TS that are meant to be built by the consumer application (Next, Gatsby, or Express APIs), but it would be way safer with Deno.

Edit:

Monorepoes also need correct support from the text editor. Currently I hit this issue with VS Code: denoland/vscode_deno#701 (comment), it won't respect the deno.jsonc of each folder.

This may be problematic if you have 2 Deno apps with different configs (this is helpful for having "/" imports to point to the root of the current folder). You can bypass this by having one single config and import_map, but this is not clean (it's like having one package.json for all your modules in a Node.js context).

[allangomessl]

you are right about monorepo expectation, but it doesn't make sense talk about it here.
we can let it for frameworks like nx or any else.

[eric-burel]

I am not sure about that, Nx and friends are mostly relevant for the "script running" and daily operations parts of monorepos. They most often delegate the workspace system to Node.js package managers, so Yarn workspaces, pnpm workspaces etc. so the first part of my answer is not solved by Nx even in the Node.js ecosystem.

Deno do not have packages, but it has "modules": how do you manage multiple modules in the same folder? That's what I mean by interconnecting packages, this is handled by package managers that are considered part of the core of Node.js, and the Deno alternative is not clear to me.

(though you are totally right that part of the problem must be solved outside of Deno)

[airtonix]

@eric-burel My experience with nxdev has left this impression on me:

tasks that behave like makefiles

• nx.dev has a different way to run and describe tasks to tasks in package.json: they respect dependencies and source inputs just like makefiles do

inbuilt generator engine

• you can create your own executors and generators for what ever language framework your project uses

the dependency graph metadata is indedependant of the underlying nodejs system

• you don't need package.json to describe the depedency graph
• i can use nx.dev to manage a pure golang project
• the dependency graph system in nx.dev is git sensitive, so making decisions in a PR or a deployment task with well tagged nx projects helps immensly on being accurate about what you're deploying or running tasks on.

tl;dr, the underlying value of nx.dev doesnt require your project to be nodejs based.

[eric-burel]

Very interesting! I would love to see an OSS demo somewhere of a Deno monorepo with Nx, I've had a lot of trouble setting Nx in a Node.js project in the past, it's a big chunk of technology with a learning curve.

[revskill10]

The accepted answer is not the answer to original question. Let me repeat again here. Does deno support monorepo ?

Answer should be yes, no, or not yet. If yes, then what's the standard practice ?

[eric-burel]

Repeating the question in an assertive tone doesn't help, see my comment above for more insights and feel free to add to the discussion.
"Supporting monorepo" doesn't make sense: you can provide ways to implement certain patterns that are useful to manage a monorepo. So it's certainly not a yes/no question, but a more complicated "how to" question.

[revskill10]

So, as i understand correctly, it's a no by default. Thanks.

[jupegarnica]

So, as i understand correctly, it's a no by default. Thanks.

Yes by default.

See #9126 (comment)

[danilo-valente]

I agree with @airtonix comment about a monorepo not being just "a folder with other folders inside".

I couple months ago I stumbled across the same limitation and found this thread, but found no suitable tools for this issue. As of today, even Nx doesn't have a good support for Deno. This is why I decided to create my own Deno monorepo manager.

Compy - Minimalist (yet helpful) monorepo manager for Deno

https://deno.land/x/compy

Disclaimer: Compy is still in early stage and some features might be redesigned in future versions. Automated testing and proper documentation is also in progress.

That said, it does provides good tooling for creating a project and its modules, adding dependencies and mapping them through import maps, running Deno's CLI commands within a module's context and linking modules between themselves. In fact, I'm currently using it in production.

Some commands include:

• compy init <project> to create a new project/workspace
• compy mod <module> to create a new module within the project
• compy add std to add the latest std version to all modules
• compy add oak v12.6.1 -m <module> to add oak@v12.6.1 to an specific module
• compy <cache|start|dev|run|test|fmt|lint> <module> to run a command within a module's context
• and more

Here's a simple (outdated) demo:

@allangomessl @puentesdiaz @foo0110 @theoparis @yinonov @eric-burel @revskill10 you might find this helpful as well.