You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In one corner @dsherret with a declarative approach
Solves the filtering use case better
Main drawback, extra features mean more syntax
Declarative approach more similar to existing popular JavaScript testing frameworks
In the other corner @lucacasonato with an imperative approach
Functionality added with an argument passed to the testing function.
It is just code.
Can't filter subtests, but this is how it works in Go and that seems fine
Both solutions are backwards compatible
🗳️ Team attending the meeting divided
Action wider polling of the core team before a final decision is made, but we need to make one.
NodeJS compatibility, what is our high-level strategy, goals, next steps?
Are we ok with the likes of Skypack and esm.sh, or are we actually trying to have full API compatibility with Node? "Node compatibility" is a nebulous concept.
std/node lacks major things like http, a lot of tools and workloads can't run on Deno because of it.
Do we see Node and Deno co-existing, or do we want to think of Node as "legacy"? (Note, there was no clear decision on this question, it was just a conversation)
@kitsonk full parity would take forever and be "useless". We should focus on particular workflows/workloads, fill in the gaps, and figure out a well supported migration path.
Should we put effort into documenting how to write code for both platforms? Yes
What Node has well established and Deno is generally lacking are well supported and performant DB drivers. This is a problem, and problem for bring workloads over from Node to Deno.
Discussion again that we need to prioritise this space, if we try to do everything we will do nothing.
If we could say "you can run your Express server under Deno faster than Node" would that encourage adoption? No clear answer
Further debate on if we focus on front-end workflows or backend servers. There were a lot of good points.
Action lack of std/node/http is a problem, no matter what we should solve that. Skypack has said they would move to std/node if we had http which would also be a win.
Action identify workflows/workloads we want to focus on and prioritise them, then figure out next steps.
No specific opposition, but there are some challenges and edge cases that need to be worked through.
Permission Flags: Instead of granular permissions, have "macro" sandbox modes (e.g. red/green/orange)
If security is impractical then it's insecure is the motivation for this suggestion.
example: deno run --security=red main.ts
There was a lot of debate and discussion about the value of this, and if it actually improves usability and security, or just sort of obfuscates it more. Further discussion to continue.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
std/node
lacks major things likehttp
, a lot of tools and workloads can't run on Deno because of it.std/node
here: https://github.com/denoland/deno_std/discussions/756std/node/http
is a problem, no matter what we should solve that. Skypack has said they would move tostd/node
if we hadhttp
which would also be a win.Deno.ConnectTlsOptions#certFile
is a bad name (Proposal: replacecertFile
in Deno.ConnectTlsOptions withcaCerts
#11608)--allow-net
(feat(runtime/permissions): support IP CIDR ranges in net allowlist #11509)red
/green
/orange
)deno run --security=red main.ts
Beta Was this translation helpful? Give feedback.
All reactions