4 ms·

Deno 1.45: Workspace and Monorepo Support

worldsayshi 2y ago
I'm currently working in a pnpm monorepo and it really seems like a potential double edged sword. On the one hand I have longed for better support for local packages in the ecosystem (which pnpm does provide, and I'm happy for it). But some weird edge cases seem to arise. Like serverless functions not being supported[1]. I suppose that's just a matter of feature maturity. The more design-level hazard of this might be that it's easier to build monorepos where everything is tightly coupled. And you end up with something that is like a single package with extra abstraction layers. 1 - https://github.com/pnpm/pnpm/issues/6259 https://github.com/pnpm/pnpm/issues/6259
- forty 2y ago
  Isn't the problem with serverless only a problem with windows not supporting zipped symlinks ? (From what I understand from the GH ticket)
  - deleted 2y ago
    [deleted]
- ricardobeat 2y ago
  Isn’t that what `pmpm deploy` solves? It should copy all packages into the target dir.
  - deleted 2y ago
    [deleted]
  - worldsayshi 2y ago
    It tries to solve it but doesn't seem to get all the way there. Symlinks are still very much present for example. But I'm still a bit confused what exactly is causing the azure function to fail so I can't say more.
bovermyer 2y ago
I wonder how this works with things like dependency management; for example, Nx lets you build all affected projects when you change one dependency's files in a monorepo. Does this do something similar?
IshKebab 2y ago
Deno is so nice for infrastructure scripting in projects. I tried to convince my company to use it but apparently one `curl` line to install it was too much to ask so now I spend half my time fighting Python, setting up venvs, working around pip bugs, etc. Yeay.
- rockyj 2y ago
  Not to mention the performance / async / memory usage benefits you would have gotten on Node/Deno (not to mention lower cloud bills). I do not know why teams doing this.
- tracker1 2y ago
  Agreed... I use deno a lot for my ~/bin directory scripts, being able to rely on direct references and just run stuff, without the npm install step is just handy in practice. That node_modules doesn't work the same as well. There are things that are somewhat annoying in practice, but shell scripting with Deno has been beyond nice to say the least.
ethegwo 2y ago
In my last job, I tried using a monorepo approach, merging about 50 microservices into a single repository. After several months of growth, the size of the entire git repository reached over 100GB. We had to create monthly checkpoints (.tar.gz) to facilitate faster time traveling or quick cloning for new team members. This experience taught me that perhaps git is not the best tool for managing a monorepo.
- mananaysiempre 2y ago
  > We had to create monthly checkpoints (.tar.gz) Not `git bundle`?
- mbb70 2y ago
  What were you checking in? I've worked in monorepos with a lot of generated code (millions of lines) and 10 years of commits and the total repo size never went over a few gb.
  - ethegwo 2y ago
    Just golang codes, there are about 500 hundreds developers work on it.
    - pas 2y ago
      someone else mentioned that the the kernel is still less than 2G
    - Risord 2y ago
      TLDR: Monorepos have no issues in "real world". (= My bubble, I am quite sure I haven't ever even met person face to face who have been in project of even 100 devs.)
    - deleted 2y ago
      [deleted]
    - Capricorn2481 2y ago
      That's billions of lines of code if it's just Golang. I would imagine most of that was autogenerated code that no one was reviewing. This is not a problem with monorepos.
deleted 2y ago
[deleted]

I'm currently working in a pnpm monorepo and it really seems like a potential double edged sword. On the one hand I have longed for better support for local packages in the ecosystem (which pnpm does provide, and I'm happy for it). But some weird edge cases seem to arise. Like serverless functions not being supported[1]. I suppose that's just a matter of feature maturity. The more design-level hazard of this might be that it's easier to build monorepos where everything is tightly coupled. And you end up with something that is like a single package with extra abstraction layers. 1 - https://github.com/pnpm/pnpm/issues/6259 https://github.com/pnpm/pnpm/issues/6259

forty 2y ago
Isn't the problem with serverless only a problem with windows not supporting zipped symlinks ? (From what I understand from the GH ticket)
- deleted 2y ago
  [deleted]
ricardobeat 2y ago
Isn’t that what `pmpm deploy` solves? It should copy all packages into the target dir.
- deleted 2y ago
  [deleted]
- worldsayshi 2y ago
  It tries to solve it but doesn't seem to get all the way there. Symlinks are still very much present for example. But I'm still a bit confused what exactly is causing the azure function to fail so I can't say more.

bovermyer 2y ago

I wonder how this works with things like dependency management; for example, Nx lets you build all affected projects when you change one dependency's files in a monorepo. Does this do something similar?

IshKebab 2y ago

Deno is so nice for infrastructure scripting in projects. I tried to convince my company to use it but apparently one `curl` line to install it was too much to ask so now I spend half my time fighting Python, setting up venvs, working around pip bugs, etc. Yeay.

rockyj 2y ago
Not to mention the performance / async / memory usage benefits you would have gotten on Node/Deno (not to mention lower cloud bills). I do not know why teams doing this.
tracker1 2y ago
Agreed... I use deno a lot for my ~/bin directory scripts, being able to rely on direct references and just run stuff, without the npm install step is just handy in practice. That node_modules doesn't work the same as well. There are things that are somewhat annoying in practice, but shell scripting with Deno has been beyond nice to say the least.

ethegwo 2y ago

In my last job, I tried using a monorepo approach, merging about 50 microservices into a single repository. After several months of growth, the size of the entire git repository reached over 100GB. We had to create monthly checkpoints (.tar.gz) to facilitate faster time traveling or quick cloning for new team members. This experience taught me that perhaps git is not the best tool for managing a monorepo.

mananaysiempre 2y ago
> We had to create monthly checkpoints (.tar.gz) Not `git bundle`?
mbb70 2y ago
What were you checking in? I've worked in monorepos with a lot of generated code (millions of lines) and 10 years of commits and the total repo size never went over a few gb.
- ethegwo 2y ago
  Just golang codes, there are about 500 hundreds developers work on it.
  - pas 2y ago
    someone else mentioned that the the kernel is still less than 2G
  - Risord 2y ago
    TLDR: Monorepos have no issues in "real world". (= My bubble, I am quite sure I haven't ever even met person face to face who have been in project of even 100 devs.)
  - deleted 2y ago
    [deleted]
  - Capricorn2481 2y ago
    That's billions of lines of code if it's just Golang. I would imagine most of that was autogenerated code that no one was reviewing. This is not a problem with monorepos.

deleted 2y ago

[deleted]