4 ms·

The new npm import is a much required step in the right direction. The next step would be to allow namespacing of other / default repositories. ``` import nam

by singularity2001 4y ago

The new npm import is a much required step in the right direction. The next step would be to allow namespacing of other / default repositories. ``` import namespace npm import { chalk } from "chalk" import { assert } from "test" … import namespace local import { chalk } from "mychalk.ts" import { assert } from "test" // who needs extensions anyways? ```

brundolf 4y ago
a) They intentionally want to segregate NPM imports, because this is a stopgap, not the way forward they're trying to lay out for the ecosystem. The future Deno is aiming for is one where you don't have repositories (as we've known them), only web domains. b) The above introduces non-standard JS syntax and semantics, which also goes against Deno's philosophy
- singularity2001 4y ago
  b) that's a valid argument. so Deno.namespace("npm") would be the way a) that's fine. In fact namespacing helps with segregation, because once there is some "npm for deno" one would just set the appropriate Deno.namespace("default") without having to touch a million import "npm:package_xyz". Explicitly repeating full paths such as import { createRequire } from "https://deno.land/std/node/module.ts https://deno.land/std/node/module.ts"; over and over again is just an ugly antipattern.
  - brundolf 4y ago
    My opinion is that imports are such a simple, rarely-modified, hard to mess up (and often automatically-managed) part of the code that it's much more valuable to have simplicity/explicitness over complex new mechanisms that save a few characters. But we can agree to disagree Another thing that helps is that in Deno, it's common to have a deps.ts file that imports and then exports all the third-party libraries in use, for the rest of the project to reference. This is mainly done to make sure everything is using the same versions of everything, but it helps with brevity too. You could even approximate your own namespacing mechanism using this pattern
  - WorldMaker 4y ago
    Deno already supports "import maps" for this. [1] There's one example in the linked article even. You create an import map JSON file that tells Deno that maps human useful "short names" and "short paths" to full URLs (including `npm:package@version` URLs). [1] https://deno.land/manual@v1.28.0/basics/modules/import_maps https://deno.land/manual@v1.28.0/basics/modules/import_maps
    - singularity2001 4y ago
      great, thanks! not fully supported in WebStorm but the future is near
    - brundolf 4y ago
      Huh. I was about to complain that this breaks with web standards, but apparently it's being proposed as a standard feature: https://github.com/WICG/import-maps https://github.com/WICG/import-maps Interesting!
      - singularity2001 4y ago
        How can it break a web standard when this server-side mess of different require(), import(), import "npm:", import ".mjs" does not directly translate to browser code anyways? Interesting indeed that you can remap whole URLs: { "imports": { "https://www.unpkg.com/vue/dist/vue.runtime.esm.js https://www.unpkg.com/vue/dist/vue.runtime.esm.js": "/node_modules/vue/dist/vue.runtime.esm.js" } } "… instead grab the one from the local server." This will surely result in much power and confused human debuggers;) Changing import maps will also be a prime target for some class of hacks.
        brundolf 4y ago
        > How can it break a web standard when this server-side mess of different require(), import(), import "npm:", import ".mjs" does not directly translate to browser code anyways? require() and .mjs are specific to Node (Deno does away with them), import() is actually a web standard. Not sure how npm: fits into things, though if you're importing an NPM dependency directly you're almost certainly pulling in some non-web stuff anyway, so maybe they just decided that was a lost cause But "web standards compatible" is one of Deno's stated goals. A whole lot of the Deno code out there (or at least a much larger portion than Node code) can be imported directly, with no preprocessinng, by browser scripts. That's a super exciting goal to work towards.

brundolf 4y ago

a) They intentionally want to segregate NPM imports, because this is a stopgap, not the way forward they're trying to lay out for the ecosystem. The future Deno is aiming for is one where you don't have repositories (as we've known them), only web domains. b) The above introduces non-standard JS syntax and semantics, which also goes against Deno's philosophy

singularity2001 4y ago
b) that's a valid argument. so Deno.namespace("npm") would be the way a) that's fine. In fact namespacing helps with segregation, because once there is some "npm for deno" one would just set the appropriate Deno.namespace("default") without having to touch a million import "npm:package_xyz". Explicitly repeating full paths such as import { createRequire } from "https://deno.land/std/node/module.ts https://deno.land/std/node/module.ts"; over and over again is just an ugly antipattern.
- brundolf 4y ago
  My opinion is that imports are such a simple, rarely-modified, hard to mess up (and often automatically-managed) part of the code that it's much more valuable to have simplicity/explicitness over complex new mechanisms that save a few characters. But we can agree to disagree Another thing that helps is that in Deno, it's common to have a deps.ts file that imports and then exports all the third-party libraries in use, for the rest of the project to reference. This is mainly done to make sure everything is using the same versions of everything, but it helps with brevity too. You could even approximate your own namespacing mechanism using this pattern
- WorldMaker 4y ago
  Deno already supports "import maps" for this. [1] There's one example in the linked article even. You create an import map JSON file that tells Deno that maps human useful "short names" and "short paths" to full URLs (including `npm:package@version` URLs). [1] https://deno.land/manual@v1.28.0/basics/modules/import_maps https://deno.land/manual@v1.28.0/basics/modules/import_maps
  - singularity2001 4y ago
    great, thanks! not fully supported in WebStorm but the future is near
  - brundolf 4y ago
    Huh. I was about to complain that this breaks with web standards, but apparently it's being proposed as a standard feature: https://github.com/WICG/import-maps https://github.com/WICG/import-maps Interesting!
    - singularity2001 4y ago
      How can it break a web standard when this server-side mess of different require(), import(), import "npm:", import ".mjs" does not directly translate to browser code anyways? Interesting indeed that you can remap whole URLs: { "imports": { "https://www.unpkg.com/vue/dist/vue.runtime.esm.js https://www.unpkg.com/vue/dist/vue.runtime.esm.js": "/node_modules/vue/dist/vue.runtime.esm.js" } } "… instead grab the one from the local server." This will surely result in much power and confused human debuggers;) Changing import maps will also be a prime target for some class of hacks.
      - brundolf 4y ago
        > How can it break a web standard when this server-side mess of different require(), import(), import "npm:", import ".mjs" does not directly translate to browser code anyways? require() and .mjs are specific to Node (Deno does away with them), import() is actually a web standard. Not sure how npm: fits into things, though if you're importing an NPM dependency directly you're almost certainly pulling in some non-web stuff anyway, so maybe they just decided that was a lost cause But "web standards compatible" is one of Deno's stated goals. A whole lot of the Deno code out there (or at least a much larger portion than Node code) can be imported directly, with no preprocessinng, by browser scripts. That's a super exciting goal to work towards.