[bastawhiz]

I like this, but unfortunately it doesn't solve one annoying problem: lexical scope doesn't work and it will fail in an unexpected way.

If you reference something lexically, your code fails at runtime. Want to use an import? You have to use import() inside the closure you pass to spawn(). Typescript doesn't know this. Your language server doesn't know this. Access a variable that shadows a built in global? Now you're accessing the built in global.

The only way this could even be addressed is by having a full on parser. Even then you can't guarantee things will work.

I think the only "fix" is for JS to introduce a new syntax to have a function that can't access lexical scope, returning a value that either extends a subclass of Function or has a cheeky symbol set on it. At least then, it'll fail at compile time.

[Etheryte]

There is a simple solution to this problem, but it's not very popular: do the same thing Workers do, require using a separate file. All the tooling works out of the box, you have no issues with lexical scoping, etc. The only downside is it's (currently) clunky to work with, but that can be fixed with better interfaces.

[buu700]

I've been using a functionally identical implementation of this since I wrote it in my startup's codebase a decade ago. It's really handy, but definitely not without edge case issues. I've occasionally had to put in workarounds for false positive TypeScript/lint errors or a tool in the bundling pipeline trying to be too clever and breaking the output.

Overall it's great, and I'm glad to see a generic implementation of it which will hopefully become a thriving open source project, but ultimately it's a kludge. What's really needed is for JS to introduce a native standardized version of this construct which TypeScript and the rest of the ecosystem have to play nice with.

[kretaceous]

A linter rule provided by the library could be helpful here. I know it's just a workaround but probably easier than going for a solution that does compile time checks.

[pwdisswordfishy]

https://github.com/tc39/proposal-module-expressions is basically that fix.

[austin-cheney]

This should be the expected behavior when multithreading. It is the expected behavior when executing a child process, such as node’s child_process.fork.

[seniorsassycat]

Fork, and normal worker threads always enter a script, there's clearly no shared lexical scope. This spawn method executes a function, but that fn can't interact with the scope outside

[throwaway17_17]

While I agree with GP that this should be the expected behavior, your comment raises what I think is a large problem/wild-goose-chase in ‘modern’ language designs implementing concurrency.

The push from language designers (this applies across the high/low level spectrum and at all ranges of success for languages) to make concurrent code ‘look just like’ linearly read, synchronous, single-threaded code is pervasive and seems to avoid large pushback by users of the language. The complaints that should be made against this syntax design become complaints that code doesn’t do what developers think it should.

My position is that concurrent (and parallel) code IS NOT sequential code and languages should embrace those differences. The move to or design of async/await is often explicitly argued for from this position. But the semantic differences in concurrent code IMO should not be obscured or obfuscated by seeking to conform that code to sequential code’s syntax.

[hombre_fatal]

As soon as I read your username, I had to read it out loud to my girlfriend. Why is it so funny

[bastawhiz]

It's expected behavior functionally, but knowing nothing of the spawn function, it's unexpected syntactically. Fork doesn't behave this way, though, because it executes a module by path, not a function.

[christophilus]

I’d love a way to be able to specify that sort of thing. I wrote a little server-side JSX rendering layer, and event handlers were serialized to strings, and so they had similar restrictions.