What does a “module” mean?
Modules are just files that are used by another file. They typically perform a singular function, provide a framework to build with, a linter… you get the idea.
How do modules work in deno?
const react = require('react');.
When we use a package manager like yarn or npm what we are doing is importing a bunch of files to our computer/server then at the top of a file we are importing them. Not terribly different from deno but instead of sourcing the files locally, we use URLs.
How is deno different from node with modules?
When you import a file using an import statement (ie.
import react from 'react') what we are doing is saying there is a module that this file depends on – in other words, it’s a dependancy.
In node you can run
npm ls and you can see the dependency tree.
One thing that you will need to do with deno that you may not need to do with node is specify the file extension (.js, .jsx, .ejs, .ts, etc…) because it explicitly needs to know what is being imported.
In Deno, you can run
deno info './filename.js'; and you will see the “deps” or dependencies.
What about external modules?
Similar to using
deno info './filename.js';, you can find the dependancies for a url.
In your terminal, run
deno info https://deno.land/std/examples/welcome.ts.
You will see something just like this (this is the 2nd time I’ve run it so what you see will likely show it’s downloading, then compiling.
Why would it be compiling? Deno recommends all modules be written in Typescript.
Wait so we are just grabbing a random url from the internet, this doesn’t sound safe, right? Absolutely, you should never click a random url let alone install it or allow it to run on your computer. If you remember us talking about the security of deno over in my “The future of backend development” article, you’ll see that it’s much safer than it would be in node due to permissions.
Generally, you can trust the deno standard library which is vetted by the deno team and we will dive more into that, 3rd Party Modules, and cache in my next article.
I hope you enjoyed this brief article on modules with deno and I look forward to writing more. My next article on deno will be about the standard library, 3rd party modules, and caching.
If you found this article helpful, give me a shout on twitter – I’d love to hear from you in the comments below or on twitter @codingwithdrewk. As always, if you found any errors, just highlight it and mash that “R” button on the right side of the screen and I’ll get those fixed right up!
Leave a Reply