3 ms·

> I just wish they also supported importing from local npm packages installed in node_modules without needing to specify a URL/full path. Import maps allow you

> I just wish they also supported importing from local npm packages installed in node_modules without needing to specify a URL/full path. Import maps allow you to do that, see: https://deno.land/manual/linking_to_external_code/import_maps https://deno.land/manual/linking_to_external_code/import_map...

nikisweeting 6y ago
Ah cool, that helps a ton. The existence of this feature as the linchpin for compatibility with npm is not clear from the rest of the Deno docs though. Perhaps it could be linked to from this page: https://deno.land/manual@v1.6.0/examples/import_export https://deno.land/manual@v1.6.0/examples/import_export. Also, it seems as though ./node_modules/ being the default could be assumed automatically though, no? "imports": { "moment": "/node_modules/moment/src/moment.js", "lodash": "/node_modules/lodash-es/lodash.js" } Considering it's the default in all other JS environments, wouldn't that save the hassle of the dev having to define this for their entire tree of JS dependencies? Then Deno would be a drop-in replacement and we could move our whole codebase over to it overnight (once the Node APIs are up to par).
- mark_and_sweep 6y ago
  > Also, it seems as though ./node_modules/ being the default could be assumed automatically though, no? No, there is no magic node_modules directory in any other JS environment, other than Node. Deno aims to be compatible with web standards. Import and import maps are web standards, require and node_modules aren't. > Deno would be a drop-in replacement and we could move our whole codebase over to it overnight The reason that you cannot move your existing codebase to Deno tonight is essentially the poor web compat of the existing Node ecosystem.
  - nikisweeting 6y ago
    Node is the standard web environment, even frontend code is built 90% of the time using Webpack or another bundler running in a node environment and pulling from node_modules. I don't think you can blame the incumbent tool with complete market dominance for "poor compatibility"... I really like the direction of the Node compatibility layer though https://deno.land/std@0.80.0/node https://deno.land/std@0.80.0/node, I suspect it will be enough to make Deno a drop in replacement soon. Now it just needs support for normal `import` statements from node_modules instead of just `require()`.
    - mark_and_sweep 6y ago
      Last time I checked jQuery was used on 9 out of 10 websites using JS with 8 out of 10 websites being powered by PHP. How dare Node not be compatible with the market dominating jQuery! Silly server-runtime not having a browser window object! > Now it just needs support for normal `import` statements from node_modules Deno will never ever do that (other than by using standardized import maps) since that's not normal (normal meaning standardized).
      - nikisweeting 6y ago
        I don't understand, jQuery works fine in node-built environments. Obviously any DOM mutation stuff stuff needs to happen in the frontend when it runs in the browser, but you can absolutely import jquery and use parts of it during server-side compiling or rendering steps in node. import $ from "jquery" > Deno will never ever do that Why would Deno take such an antagonistic approach to supporting the most common setup that everyone uses with npm? Wouldn't it be trivial to just fall back to checking node_modules for named packages? I want to use Deno! This seems like it's deliberately making transitions difficult for anyone using npm.
        mark_and_sweep 6y ago
        Sorry, jQuery was a bad example - I remember jQuery not working in Node at all, but that was roughly 10 years ago. Things have improved. The fact remains that the most popular JS env is the browser. It has APIs such as window which are not compatible with Node and Node has APIs which are not compatible with the browser like __dirname or require. That's why tools such as browserify and webpack exist to bridge the gap. In Deno the gap is much closer. Obviously, the Deno namespace is not available in the browser (but there's a shim for most APIs, e.g. Deno.writeFile and readFile are implemented with a virtual FS) and some web APIs are not available in Deno (yet), but the compat story is much better. This is no surprise since web compat is a core goal of Deno. Node compat is not. > Wouldn't it be trivial to just fall back to checking node_modules for named packages? No, the resolution algo is not trivial (nor performant). Also, it's not necessary: There is already a standard for how to import code in JS; it's import statements. Import statements do not allow named packages, e.g. import $ from "jquery" does not work in the browser. Except, again, import maps.

nikisweeting 6y ago

Ah cool, that helps a ton. The existence of this feature as the linchpin for compatibility with npm is not clear from the rest of the Deno docs though. Perhaps it could be linked to from this page: https://deno.land/manual@v1.6.0/examples/import_export https://deno.land/manual@v1.6.0/examples/import_export. Also, it seems as though ./node_modules/ being the default could be assumed automatically though, no? "imports": { "moment": "/node_modules/moment/src/moment.js", "lodash": "/node_modules/lodash-es/lodash.js" } Considering it's the default in all other JS environments, wouldn't that save the hassle of the dev having to define this for their entire tree of JS dependencies? Then Deno would be a drop-in replacement and we could move our whole codebase over to it overnight (once the Node APIs are up to par).

mark_and_sweep 6y ago
> Also, it seems as though ./node_modules/ being the default could be assumed automatically though, no? No, there is no magic node_modules directory in any other JS environment, other than Node. Deno aims to be compatible with web standards. Import and import maps are web standards, require and node_modules aren't. > Deno would be a drop-in replacement and we could move our whole codebase over to it overnight The reason that you cannot move your existing codebase to Deno tonight is essentially the poor web compat of the existing Node ecosystem.
- nikisweeting 6y ago
  Node is the standard web environment, even frontend code is built 90% of the time using Webpack or another bundler running in a node environment and pulling from node_modules. I don't think you can blame the incumbent tool with complete market dominance for "poor compatibility"... I really like the direction of the Node compatibility layer though https://deno.land/std@0.80.0/node https://deno.land/std@0.80.0/node, I suspect it will be enough to make Deno a drop in replacement soon. Now it just needs support for normal `import` statements from node_modules instead of just `require()`.
  - mark_and_sweep 6y ago
    Last time I checked jQuery was used on 9 out of 10 websites using JS with 8 out of 10 websites being powered by PHP. How dare Node not be compatible with the market dominating jQuery! Silly server-runtime not having a browser window object! > Now it just needs support for normal `import` statements from node_modules Deno will never ever do that (other than by using standardized import maps) since that's not normal (normal meaning standardized).
    - nikisweeting 6y ago
      I don't understand, jQuery works fine in node-built environments. Obviously any DOM mutation stuff stuff needs to happen in the frontend when it runs in the browser, but you can absolutely import jquery and use parts of it during server-side compiling or rendering steps in node. import $ from "jquery" > Deno will never ever do that Why would Deno take such an antagonistic approach to supporting the most common setup that everyone uses with npm? Wouldn't it be trivial to just fall back to checking node_modules for named packages? I want to use Deno! This seems like it's deliberately making transitions difficult for anyone using npm.
      - mark_and_sweep 6y ago
        Sorry, jQuery was a bad example - I remember jQuery not working in Node at all, but that was roughly 10 years ago. Things have improved. The fact remains that the most popular JS env is the browser. It has APIs such as window which are not compatible with Node and Node has APIs which are not compatible with the browser like __dirname or require. That's why tools such as browserify and webpack exist to bridge the gap. In Deno the gap is much closer. Obviously, the Deno namespace is not available in the browser (but there's a shim for most APIs, e.g. Deno.writeFile and readFile are implemented with a virtual FS) and some web APIs are not available in Deno (yet), but the compat story is much better. This is no surprise since web compat is a core goal of Deno. Node compat is not. > Wouldn't it be trivial to just fall back to checking node_modules for named packages? No, the resolution algo is not trivial (nor performant). Also, it's not necessary: There is already a standard for how to import code in JS; it's import statements. Import statements do not allow named packages, e.g. import $ from "jquery" does not work in the browser. Except, again, import maps.