4 ms·

> Deno appears to be trying to become the Linux of Javascript Deno always sounded more "like the Plan 9 of Javascript" personally to be honest. It seems to be

• halfmatthalfcat 7y ago
  Deno was always Typescript-first fwiw
  • jakear 7y ago
    I have doubts about how this could possibly work. The idea is you pull a .ts file directly, right? Then your local ts-in-debo compiles that to extract typedefs for intellisense/etc and the JS. What happens when it was created for a different version of typescript than what you’re running? Or if it was created targeting different flags that what you’re using? This will cause lots of problems: I’m running my project with ts 3.6. Library upgraded to 3.7 and adds null chaining operators. Now my package is broken. In node land, you compile the TS down to a common target before distributing so you don’t have this problem. Similar, I’m using 3.8 and package upgrades to 3.9 and starts using some new builtin types that aren’t present in my TS. Now my package is broken. Previously you’d export a .d.ts targeting a specific version and again not have this problem. Or, I want to upgrade to 3.9 but it adds some validations that cause my dependencies to not typecheck, now what? Or, I’m using strictNullChecks. Dependent package isn’t. Trying to extract types now throws. I’ve brought these all (And many other concerns) up to the deno folks on numerous occasions And never gotten a answer more concrete than “we’ll figure out what to do here eventually”. Now 1.0 is coming, and I’m not sure they’ve solved any of these problems.
    • mtone 7y ago
      On the other hand, trying to setup a typescript monorepo with shared/dependent projects is a huge pain since everything needs to be transposed to intermediary JS that severely limits or breaks tooling. Even TS project references make assumptions about the contents of package.json (such as the entry file), or how the compiler service for VsCode preloads types from @types/ better than for your own referenced projects, which sadly ties TS to that particular ecosystem. Language version compatibility is a good point, but perhaps TSC could respect the compiler version and flags of each package's tsconfig.json, and ensure compatibility for minor versions of the language? Since I enjoy working in TS I'm willing to wait it out as well, the pros far outweigh the cons. Now that GitHub/MS acquired NPM, I have hopes that it will pave the way to make TS a first-class citizen, though I don't know if Deno will be part of the solution or not.
      • jakear 7y ago
        > TSC could respect the compiler version and flags of each package's tsconfig.json That’s the problem - there is no tsconfig.json. You’re only importing a single URI.
        • mtone 7y ago
          I see. While I don't know the details, it seems it would promote the use of "entry/barrel" files once again.
    • nitsky 7y ago
      > I’m running my project with ts 3.6. Library upgraded to 3.7 and adds null chaining operators. Now my package is broken. Isn't this similar to not upgrading node and using an updated version of an npm package that calls a new function added to the standard library? All npm packages have a minimum node version, and similarly all deno code has a minimum deno version. Both use lockfiles to ensure your dependencies don't update unexpectedly. > Or, I’m using strictNullChecks. Dependent package isn’t. This definitely sounds like a potential problem. Because Deno enables all strict checks by default, hopefully library authors will refrain from disabling them.
      • jakear 7y ago
        Node updates much less frequently than TS, so even if it was a problem before, it’s more of a problem now.
        • recursive 7y ago
          Not sure about that. https://nodejs.org/en/download/releases/ https://nodejs.org/en/download/releases/
          • jakear 7y ago
            Rephrase: people use new TS features much more often than they use new Node features.
            • recursive 7y ago
              That might be true in general, but I seem to run into problems with the two with about equal frequency. One of the recent ones I ran into with node was stable array sort.
              • nitsky 7y ago
                Yes, npm package maintainers spend a lot of time on node version compatibility. Here is a quote from prettier on their recent v2 release: > The main focus should be dropping support for unsupported Node.js versions. https://github.com/prettier/prettier/issues/6888 https://github.com/prettier/prettier/issues/6888
• tomphoolery 7y ago
  The permissions management is a little tricky to think about at first, but once you get the hang of it I think it's actually quite nice. Setting strict permissions on CLI tools help to ensure that the CLI isn't doing anything nefarious when you're not looking (like sending telemetry data). Since this CLI has --allow-run, I can also have it execute a bin/server script that _does_ have network and read/write permissions, but only in the current app directory.
  • jakear 7y ago
    The problem I saw was how quickly you need to open up the permissions floodgates. I saw them live-demo a simple http server, and to do something as basic as that you need to open up full file system and network access. So if you’re doing anything like setting up a server (i.e. one of the core things one does when using a server-side scripting language), you’re back to square 1.
    • jakear 7y ago
      Ah never mind, I see they now have finer grained scopes. That should help.