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?
With ES6, we import javascript files from one file into another using import statements or with commonJS using something like 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.
Next...
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!
Drew is a seasoned DevOps Engineer with a rich background that spans multiple industries and technologies. With foundational training as a Nuclear Engineer in the US Navy, Drew brings a meticulous approach to operational efficiency and reliability. His expertise lies in cloud migration strategies, CI/CD automation, and Kubernetes orchestration. Known for a keen focus on facts and correctness, Drew is proficient in a range of programming languages including Bash and JavaScript. His diverse experiences, from serving in the military to working in the corporate world, have equipped him with a comprehensive worldview and a knack for creative problem-solving. Drew advocates for streamlined, fact-based approaches in both code and business, making him a reliable authority in the tech industry.