wperron

6 ms·

1.
by wperron 4y ago
Actually the most apt comparison here is if Bob sends over a contract for $1000, but then goes "oh no I'm sorry, I really meant $800" There are not takebacks here. Actually, I know there legally could be, as these situation
2.
by wperron 4y ago
If you're not following those companies' offerings then it stands to reason you haven't heard about it but all three of them did broadcast pretty widely that they were using Deno, I would assume quite a few people were aware
3.
by wperron 4y ago
It's not a hot take, it's just a bad take, and a complete failure to understand the value proposition of these types of offerings (and why we're seeing so many of them pop up these days)
4.
by wperron 4y ago
Has been possible (and surprinsingly easy) for a while through CDNs like skypack or esm.sh
5.
by wperron 4y ago
Netlify, Supabase and Slack whitelabelling Deno Deploy for starters, I'm sure there are others out there self-hosting as well
6.
by wperron 4y ago
It's really not, and it's even saying so explicitly in the article.
7.
by wperron 5y ago
The whole conversation is a bit hard to follow, there was an issue initially, then this PR and then another Discussion that's linked somewhere in the PR. I'll let you go read those, I don't recall exactly what decisions were
8.
by wperron 5y ago
Hi, I'm one of those people in the PR advocating for this change :) I think you may have missed the point of comparing the security aspects to NPM. By saying "it's no less secure" it's not saying "well it'
9.
by wperron 5y ago
If you actually read the (admittedly long) thread, it's pretty clear that those imports are not resolved at runtime, and Deno has never evaluated imports at runtime either. Dependencies get evaluated and downloaded prior to start
10.
by wperron 5y ago
> I’d argue URLs are fine until you get massive use of a single package and it weaves itself into a complex dependency tree across multiple other critical projects. Then you worry about the what if’s. This is already an issue with npm. M
11.
by wperron 5y ago
deno.land/x is _not_ a central registry. It's something we maintain as a convenience to the community, but we actually go to great lengths to make sure it doesn't receive preferential treatment from the CLI. Importing modules
12.
by wperron 5y ago
yeah, it's a bit awkward and you have to dig through the docs to find it. We're thinking about making it the default behavior.
13.
by wperron 5y ago
Transpiling TS to JS on startup does incur a cold start penalty, you can minimize it by using the `--no-check` option to transpile with SWC instead of TSC but it's still there. On subsequent runs though, it'll start up instantly b
14.
by wperron 5y ago
> Prometheus has a pull model, which I can see the appeal of, but I don't really like. That's such an antiquated statement at this point. Prometheus might have been pull-only in a distant past, but the remote write protocol has
15.
by wperron 5y ago
Whenever someone tells me "it's just syntax sugar, it doesn't matter" I usually point them to mathematics. This is both beautiful and horrifying in equal measure and _I love it_
16.
by wperron 5y ago
There's a couple of reasons. Internally, there's quite a few things that we do in Rust that aren't actually taken care of by TypeScript -- Having our own LSP allows us to connect those bits (like the module graph resolver for
17.
by wperron 5y ago
Pro tip: don't import those libs from deno.land/x. The runtime is agnostic to where you're pulling libs from, and that's by design. The AWS SDK v3 for example works great through the Skypack CDN, and you're pulling
18.
by wperron 5y ago
Sorry you've had this experience -- the LSP is improving a lot with every release, this one included, try it out and let us know what you think. We really appreciate issues for the LSP on GH
19.
by wperron 5y ago
The canonical answer is _maybe_. If your Node lib relies on Node built-ins, you won't be able to import it directly from GitHub for example. However, CDNs like Skypack and esm.sh do polyfill some of those to Deno. Your mileage may vary
20.
by wperron 5y ago
Thanks for reporting, we recently moved our blog to deno.com/blog and haven't updated the post -- we'll fix that as soon as possible
21.
by wperron 5y ago
Insofar as we take `.ts` files seamlessly yes -- though to be clear, one does not simply "run" TypeScript. There are no runtimes for TypeScript directly (there's AssemblyScript that _looks_ like TypeScript, but isn't exa
22.
by wperron 5y ago
We most certainly did not, TypeScript is and continues to be a primary concern for us and we plan on continuing to support it as a first-class citizen of the ecosystem
23.
by wperron 5y ago
_If_ the browsers do get a std lib akin to what we've built for deno, I would be comfortable archiving the deno_std repo and pointing people to use the browser one. We're not yet 100% compatible with browsers in the stdlib, but be
24.
Ask HN: Examples of NPM unilaterally removing packages
1 points by wperron 6y ago|1 comments
25.
by wperron 6y ago
It's important to remember that while, yes, CommonJS made Node popular, it did so because it filled a void in the Javascript syntax and specs. There was nothing to formalize the concept of a "package" back then. That's n
26.
by wperron 6y ago
to be fair, you _should_ probably already be proxying npm and importing from an internal domain (same would be true in any language, really) The truth is, even with a centralized repository, we're still importing user-code, made by hum
27.
by wperron 6y ago
Maybe... it depends on the amount of _trust_ that you put in the remote domain. My prediction is that the Deno ecosystem will aggregate around a few, large repositories that will have good guarantees araound immutability and good track reco
28.
by wperron 6y ago
_If_ the node library uses explicit file imports, and ESM instead of CJS, it _is_ already possible to just do `npm install` and import from "./node_modules" -- again the problem is that Node's import resolution algorithm
29.
by wperron 6y ago
The beauty of Deno is that it's agnostic about where you import your code; At the moment deno.land/x only allows tags to be published - no semver range resolution, and doesn't allow versions to be removed/update. nest.la