Does deno support monorepo? #9126
-
|
Does it support monorepo? |
Beta Was this translation helpful? Give feedback.
Replies: 10 comments 18 replies
-
|
Can you elaborate on what it means to support monorepo? :) |
Beta Was this translation helpful? Give feedback.
-
|
i think is this : |
Beta Was this translation helpful? Give feedback.
-
|
Go also supports monorepo. |
Beta Was this translation helpful? Give feedback.
-
|
At the end, Deno in 2022, support workspace? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
@allangomessl you mean something similar to nx.dev? I am interested to know if there's any. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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
And like @eric-burel says #9126 (reply in thread):
|
Beta Was this translation helpful? Give feedback.
-
|
So what's the real answer ? Update : yes |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
I stopped using Deno for now, but right after this question I discovered Thank you guys. |
Beta Was this translation helpful? Give feedback.
-
|
how does this relate? in what context are you using import maps? |
Beta Was this translation helpful? Give feedback.
-
|
we can organize our imports between modules, but I was unfortunate when I used the term I think this is not idea of Deno, Deno is runtime and doesn't need to implement tools like monorepo. |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
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. 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). |
Beta Was this translation helpful? Give feedback.
-
|
you are right about monorepo expectation, but it doesn't make sense talk about it here. |
Beta Was this translation helpful? Give feedback.
-
|
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) |
Beta Was this translation helpful? Give feedback.
-
|
@eric-burel My experience with nxdev has left this impression on me: tasks that behave like makefiles
inbuilt generator engine
the dependency graph metadata is indedependant of the underlying nodejs system
tl;dr, the underlying value of nx.dev doesnt require your project to be nodejs based. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 ? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
So, as i understand correctly, it's a no |
Beta Was this translation helpful? Give feedback.
-
Yes by default. See #9126 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
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
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:
Here's a simple (outdated) demo: @allangomessl @puentesdiaz @foo0110 @theoparis @yinonov @eric-burel @revskill10 you might find this helpful as well. |
Beta Was this translation helpful? Give feedback.
-
|
I'm struggling to setup deno2 within a monorepo. I looked at the official page but still can't get it to recognise paths and modules. This is my structure (pretty standard):
{
"workspace": [
"./apps/web",
"./apps/macos",
"./packages/ui"
],
"imports": {
"vite": "npm:vite@^6.2.2"
},
"$schema": "https://deno.land/x/deno/cli/schemas/config-file.v1.json"
}
{
"tasks": {
"dev": "vite dev"
}
}
{
"tasks": {
"dev": "tauri dev"
},
"imports": {
"@tauri-apps/cli": "npm:@tauri-apps/cli@^2.3.1"
}
}
{
"name": "@package/ui",
"exports": "./mod.ts",
"imports": {
"lucide-svelte": "npm:lucide-svelte@^0.482.0"
}
}
export * from "./components/index.ts";
export { default as Button } from "./Button.svelte";And then running from the root Is this how I'm supposed to set it up? Asking because it doesn't work when trying to import stuff from a /web page e.g. with import { Button } from "@package/ui"; |
Beta Was this translation helpful? Give feedback.
-
|
I believe you're missing a version argument in your @package/ui Edit: You'd also do |
Beta Was this translation helpful? Give feedback.
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