prom candy posted:

One simple and ridiculous tip for making deep copies:

code:

const myObj = { some: { deeply: ['nested', 'structure'] } }
const myObjCopy = JSON.parse(JSON.stringify(myObj))

Don't hate the player

gbut posted:

As long as you're only working with JSON-compatible objects. You can't serialize a function.

Vino posted:

The perf of that will be terrible

Vino posted:

The perf of that will be terrible and I hope there are no uncopyable objects in there like mutexes (do those exist in javascript?) but if you don't care about perf I applaud you.

prom candy posted:

One simple and ridiculous tip for making deep copies:

code:

const myObj = { some: { deeply: ['nested', 'structure'] } }
const myObjCopy = JSON.parse(JSON.stringify(myObj))

Don't hate the player

Jabor posted:

If you put code at the top level in your file, it will run immediately when your file is loaded. That's probably not what you want, and almost certainly isn't what anybody using your file wants.

Your file should just define functions and classes and the like, and only actually do stuff when those functions are called.

Vino posted:

I'm the only one using this code, it's a small game. I don't usually write code straight into files but the one line in main.js is initializing stuff. You have to have at least one line of code in the top level or the game won't do anything right?

Vino posted:

Anyway why is it that C is undefined? What exactly does import do if not make sure C is defined? c.js is before main.js in my index.htm file, shouldn't c.js have run first, therefore defining C, then main.js uses c, and everything is OK? Why does deleting F1() matter? I never even actually call F2()!

Vino posted:

OK I'm pretty sure I'm not imagining things here:

https://codesandbox.io/s/festive-shirley-sfrmd8

Basically if I have two files that both define a type and then use each other's type

a.js

code:

import { B } from "./b.js";

export class A {}

console.log(B);
let b = new B();
console.log(b);

b.js

code:

import { A } from "./a.js";

export class B {}

console.log(A);
let a = new A();
console.log(a);

You'll get:

code:

TypeError
undefined is not a constructor (evaluating 'new _a.A()')

What's happening here? Is the only solution to separate types and code? Or make a big types.ts file that re-exports all of the types?

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.

Can I "overwrite" modules in the module tree by npm linking after installing them as dependency?

Vino posted:

OK but what about this

c.js

code:

import { F1 } from "./main.js"

export class C { }

export function F2() {
	F1(); // Delete this and C is no longer undefined
}

main.js

code:

import { C } from "./c.js"

export function F1() {
}

let c = new C(); // C is undefined

I'm the only one using this code, it's a small game. I don't usually write code straight into files but the one line in main.js is initializing stuff. You have to have at least one line of code in the top level or the game won't do anything right?

Anyway why is it that C is undefined? What exactly does import do if not make sure C is defined? c.js is before main.js in my index.htm file, shouldn't c.js have run first, therefore defining C, then main.js uses c, and everything is OK? Why does deleting F1() matter? I never even actually call F2()!

Doom Mathematic posted:

Yes, you can npm link in the way you described.

I can also give you some unhelpful non-advice, like: if the two packages are so tightly coupled in their behaviour that they have to be developed in tandem in this way, it might be that they shouldn't be separate packages at all. Conversely, if they are truly separate packages, it should be possible for you to do the necessary work in package A, test, document and publish those changes, then switch over to package B and consume the new functionality from the new version of A as a distinct task. A good hint about when A and B can be merged is if A has no consumers other than B.

Vino posted:

Thank you for the explanations. Makes a little bit more sense.

So this can be solved with some kind of packager? I am using npm, which packager could I use?

Or is there some way I can organize my files to keep things simpler? Like have a rule that all top level code should be in one file that has no function definitions or classes, would that work?

Combat Pretzel posted:

How do you go about developing multiple interdependent modules at once?

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.

Can I "overwrite" modules in the module tree by npm linking after installing them as dependency?

N.Z.'s Champion posted:

Combat Pretzel posted:

So long I have the package directories set up in the workspaces section of root package.json, I can refer to the packages by version number instead of path in the dependencies sections where necessary, and npm does the rest?

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

docs...NPM or Yarn

prom candy posted:

I'd recommend using some kind of tool for this, like Turborepo or Nx.

Combat Pretzel posted:

I just looked at Turborepo, it mentions a sister project, which is yet another packer bundler, whatever. FFS.

prom candy posted:

Sir this is the javascript thread

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?

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)