|
Combat Pretzel posted:How do you go about developing multiple interdependent modules at once? So far I've been npm linking thinks. But for debugging an upcoming Electron feature (and other things), I've been running a private repo via verdaccio and installing the other projects the proper way (which also allows deduping). But that's sure a pain in the rear end when you're working on two things at once across the modules. The "state of the art" right now is to use workspaces to solve this very problem. Think of it like setting up an environment where all of the workspace dependencies are "linked" into the root project by default. Yep it's one of these.
|
#
¿
Jun 27, 2023 21:20
|
|
|
|
| # ¿ May 10, 2024 21:55 |
|
|
N.Z.'s Champion posted:Yep. Just make sure the version numbers are exactly same or else NPM won't find it and it will try to download it from NPMJS.com if the workspace version is in range of any dependency request in your entire package tree it will be used ETA: your root project will also always get the workspace no matter what you have defined in your dependencies, version is ignored in this case. El Gar fucked around with this message at 15:00 on Jun 28, 2023 |
|
#
¿
Jun 28, 2023 14:56
|
|
|
M31 posted:In Bun/Deno/Webworkers the basic HTTP server just takes a (req: Request) -> Response function. Does anybody know if there is something similar in Node that I'm overlooking, or some NPM package that implements this? Unless I'm missing something you just described node's http/https server.
|
|
#
¿
Jun 29, 2023 18:27
|
|
|
M31 posted:Ah, sorry, should have been more explicit. The Node one uses Node specific request/response objects, while the other runtimes use the standardized ones (the same ones that are used in the fetch api) Node.js has had the fetch api since somewhere in v17 so anything v18 and above is gonna have it. If you're doing client requests just use that. If you're building an http/https server yeah find a framework you like.
|
|
#
¿
Jun 30, 2023 15:24
|
|
|
In all likelihood it just wasn't on the radar. Focus was on making it a very basic iterator like Map. All of the methods there are either specific to basic Set functionality (has, add, clear, delete) or came with it being an iterator (forEach, entries, keys, values) Arrays in JS don't have intersection either so there wasn't any sort of parity to try to keep there. Fwiw "[...x]" re-casts your entire set as an array in memory. Iterate through the Set itself and conditionally add to a new Set if this is something you're actually wanting to do in your code.
|
|
#
¿
Aug 18, 2023 19:47
|
|
|
teen phone cutie posted:just installed our node_modules with bun instead of npm and it was 1.7 seconds vs. 14 Global cache w/ the packages already un-tarred and the files hard linked in. You're sharing your node_modules with every other installation on your hard drive, that's the tradeoff.
|
|
#
¿
Sep 14, 2023 20:57
|
|
|
necrotic posted:No. That’s how pnp or whatever works too, if I remember right. Yes pnpm works the same way. huhu posted:Why is this so wrong? Nothing inherently wrong with this it's just a different way of doing things. It's up to you to decide if you're ok with it. smackfu posted:A decent number of packages broke when yarn did it but that was years ago so I would think most stuff can deal with a shared location now. Yarn has a "pnp" mode still it's just not the default. npm has one too but it still untars the package from the cache and each project is in isolation from the next, untarred packages are in a local ".store/" directory inside node_modules.
|
|
#
¿
Sep 15, 2023 18:21
|
|
|
|
| # ¿ May 10, 2024 21:55 |
|
|
Please also note how the example given there is declaring typescript as a peerDependency. This is more important than folks may realize, because it tells npm et al that typescript needs to live alongside your package in that version, not just as a subdependency. One reason for this is because in a typical typescript app, if you have multiple versions of typescript in your tree you get some unexpected breakages. Peer dependencies are an attempt to mitigate this because npm will warn if there is an incompatibility between peerDependencies, whereas with normal ones it will just put whatever version works into your packages subdependencies. They don't totally solve the problem, and the end-user needs to do their own due diligence to make sure only one copy of typescript is in their tree, but setting it as a peerDependency makes that job easier and is more helpful to the community in general. This is also why it's best to still use ranges, even if you're setting an upper bound. If you pin to a specific typescript version it is virtually impossible to deduplicate typescript unless every single dependency in your tree has that exact version in range. If even one other pins to a different version you're either out of luck or have to start implementing overrides.
|
|
#
¿
Jan 2, 2024 21:31
|
|