Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deno 1.6 supports compiling TypeScript to a single executable

github.com

Post reply on HN
Print view View original

81–90 of 284 posts

Re: Deno 1.6 supports compiling TypeScript to a single executable

#81

Post by philips »

nikisweeting wrote: post #78
mark_and_sweep wrote: post #75

Earlier quoted context omitted.

> Using URLs means there are no rules enforced How is using a URL different from using a NPM package? In both cases you can specify a module, a version, and need to trust some remote server that it is sending you the correct files. > the code hosted at that URL can change out from under you without any warning The same can and has happened with NPM. See left-pad.

The difference is that NPM as an org has a lot more to lose if they mess up everyones packages or serve incorrect versions than some random person's website. Left pad was promptly fixed! That's an argument for a centralized package manager, not against. If it were hosted on some private server we'd all still be screwed. https://www.npmjs.com/package/left-pad

I think that is a strong argument for a community immutable cache like Go uses though. Not a centralized namespace.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#82

Post by apatheticonion »

mpoteat wrote: post #65
bartlomieju wrote: post #53

Earlier quoted context omitted.

Deno is a JavaScript runtime much like Node. For the reasons on why creating Deno I recommend "10 Things I Regret About Node" by Deno's author [1] Deno is different than Node in several aspects; most notably: - Deno supports only ES modules, there's no built-in support for CommonJS modules - Deno's APIs are all promised based - Deno does not use NPM, instead it can pull code from any URL, much like browsers do - Deno…

Personally I appreciate being able to choose my linter, compiler, dialect etc. I also tend to prefer distributed solutions. Deno running the entire environment is a negative for me, at least for now. To me, it just shows an approach of ignoring what already exists and reinventing the wheel. I've tried to get Deno to work before in production, but it had so many compatibility issues last I tried it would take weeks or…

I did too, but the amount of compiler configurations out there kills me.

If you write a library, you need to support several export types for node packages. In your `package.json` you must include a `main` `module` and `exports` object and provide two compiled outputs, one commonjs and one es modules.

Then you need to worry about mutating import paths to include the file extension, which can cause trouble when you keep the commonjs and esmodule files in the same folder.

Also the esmodule loader in node doesn't have access to things like `__dirname`, so certain things can break.

not to mention node_modules...

It's like IE support but on the back end.

Then you step into the front end and it's another whole layer of chaos.

Give me opinionated compilers with minimal configuration and let me write code.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#83

Post by miohtama »

cocktailpeanuts wrote: post #51
j1elo wrote: post #29

I've been using vercel/pkg with great success, in order to achieve a similar target and package a whole application into a standalone executable: https://github.com/vercel/pkg This can be useful for people wanting to do this with Node. It's nice to have a single file that can be started right away without any external dependency. And also, it prevents from having to distribute the full sources. Kudos to the Deno devs…

I'm not very familiar with Deno but I wonder how deno compile compares to pkg when it comes to native modules. One of my gripes with PKG (and all other node.js packaging tools) has been that it's a pain in the ass to package when your dependency includes a native module, for example SQLite. Since Deno has a different architecture and works in different ways, thought I would ask just in case there's a solution for thi…

WebAssembly fixes this.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#84

Post by nikisweeting »

philips wrote: post #81
nikisweeting wrote: post #78

Earlier quoted context omitted.

The difference is that NPM as an org has a lot more to lose if they mess up everyones packages or serve incorrect versions than some random person's website. Left pad was promptly fixed! That's an argument for a centralized package manager, not against. If it were hosted on some private server we'd all still be screwed. https://www.npmjs.com/package/left-pad

I think that is a strong argument for a community immutable cache like Go uses though. Not a centralized namespace.

I think go is the perfect example of how not to do module source distribution. Because of their URL dependency system Golang projects work great as static binaries, but they're almost impossible to distribute as source builds via system package managers. A lot of my arguments for why this is a bad thing are already laid out here: https://docs.monadical.com/s/against-curl-sh (I don't know how many more replies we have left before we hit the HN nesting limit, but this is a thing I care deeply about and I'm down to keep chatting on Twitter or other forums if anyone here prefers)

Re: Deno 1.6 supports compiling TypeScript to a single executable

#85

Post by jay_kyburz »

nikisweeting wrote: post #63
bartlomieju wrote: post #60

Earlier quoted context omitted.

> We're never going to put URLs into our imports because we want to be able to run things offline without depending on 3rd party servers to stay up over time, but if we can depend on local ./node_modules libs once compatibility is improved then that's great. You can achieve the same thing with Deno! By default Deno downloads all dependencies into a central cache directory, but by providing DENO_DIR env variable with…

Local caching alone loses all the benefits of using a package manager though. I want to have a central repository of all the package versions with enforced monotonically increasing version numbers and a public, explicit chain of trust. Otherwise it's basically curl | sh with all its associated problems https://docs.monadical.com/s/against-curl-sh Using URLs means there are no rules enforced, the code hosted at that U…

I would probably just vendor them into my own directory structure and import them as a local module.

You lose automatic updating, but I'm not sure I want that anyhow. A script that goes looking for new versions of 3rd party modules would be fairly trivial I think.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#86

Post by marcopolo »

tryptophan wrote: post #20
echelon wrote: post #9

Earlier quoted context omitted.

A lot of languages are doing single static binary deploys now. Rust, Nim, Go. It's a really nice pattern. Static binaries are so much easier that the gross PHP / Ruby / Python pattern that has to ship directories full of files that (usually) have to be put in the correct place. It's also easier than shipping a runtime like a JVM. With a single binary, containers get even slimmer.

Yeah, its especially horrible in python for webdev. How are you supposed to deploy django/flask projects when NOT using docker or some PassS? I haven't figured out anything better than a git pull script to update things. I can't imagine there is nothing better in 2020.

You may be interested in Nix. It can track all the dependencies of your project. So you d an copy them to a server, or Tarball them, or just run them with Nix on the server. It also has a nice property that you only ship what is necessary, since it keeps track of all dependencies.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#88

Post by nikisweeting »

jay_kyburz wrote: post #85
nikisweeting wrote: post #63

Earlier quoted context omitted.

Local caching alone loses all the benefits of using a package manager though. I want to have a central repository of all the package versions with enforced monotonically increasing version numbers and a public, explicit chain of trust. Otherwise it's basically curl | sh with all its associated problems https://docs.monadical.com/s/against-curl-sh Using URLs means there are no rules enforced, the code hosted at that U…

I would probably just vendor them into my own directory structure and import them as a local module. You lose automatic updating, but I'm not sure I want that anyhow. A script that goes looking for new versions of 3rd party modules would be fairly trivial I think.

Vendoring is a last resort, that sounds like going back to the stone ages of package management. Why would I want that?

Re: Deno 1.6 supports compiling TypeScript to a single executable

#89

Post by jay_kyburz »

mark_and_sweep wrote: post #75
nikisweeting wrote: post #63

Earlier quoted context omitted.

Local caching alone loses all the benefits of using a package manager though. I want to have a central repository of all the package versions with enforced monotonically increasing version numbers and a public, explicit chain of trust. Otherwise it's basically curl | sh with all its associated problems https://docs.monadical.com/s/against-curl-sh Using URLs means there are no rules enforced, the code hosted at that U…

> Using URLs means there are no rules enforced How is using a URL different from using a NPM package? In both cases you can specify a module, a version, and need to trust some remote server that it is sending you the correct files. > the code hosted at that URL can change out from under you without any warning The same can and has happened with NPM. See left-pad.

Using URLs is like having an iframe to somebody else's website on your website.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#90

Post by kumarvvr »

I wonder if it's possible for TypeScript to be a .NET CLR supported language. It would be great to have a powerful scripting language for the .NET Ecosystem.

I know C# can be used for scripting, but I want something like Python, an easy to use, dynamic language that has the performance of the .NET VM

Post reply on HN