Timeline for How do I resolve "Cannot find module" error using Node.js?
Current License: CC BY-SA 4.0
33 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| S Aug 5, 2023 at 10:04 | history | suggested | Isa | CC BY-SA 4.0 |
Add a Wayback Machine mirror to the kodfabrik link since that website seems to have been down for a long while
|
| Aug 2, 2023 at 16:02 | review | Suggested edits | |||
| S Aug 5, 2023 at 10:04 | |||||
| Apr 18, 2022 at 10:15 | comment | added | numan | Ironically, the link to the kodfabrik is broken :D | |
| S Mar 17, 2020 at 1:34 | history | suggested | Charlie Bamford | CC BY-SA 4.0 |
Updated a deadish link.
|
| Mar 16, 2020 at 23:26 | review | Suggested edits | |||
| S Mar 17, 2020 at 1:34 | |||||
| S Aug 22, 2019 at 13:18 | history | suggested | NiklasPor | CC BY-SA 4.0 |
fix broken package-lock.json url
|
| Aug 22, 2019 at 10:51 | review | Suggested edits | |||
| S Aug 22, 2019 at 13:18 | |||||
| S Aug 22, 2019 at 8:36 | history | suggested | NiklasPor | CC BY-SA 4.0 |
add short text to package-lock.json which is the goto method nowadays for managing exact dependencies
|
| Aug 22, 2019 at 6:25 | review | Suggested edits | |||
| S Aug 22, 2019 at 8:36 | |||||
| Aug 8, 2016 at 19:28 | comment | added | smorhaim | Maybe a bit late to the party but, Bill is right. It is just tedious. A middle ground approach is to develop, based on NPM (meaning, not committing the libraries) for development and having developers use NPM. Then for production, moving "release" packages, meaning, including all the dependencies. Releasing via GIT and expecting NPM to manage dependencies is not a good practice. | |
| Jun 1, 2016 at 22:50 | history | edited | shmosel | CC BY-SA 3.0 |
deleted 1 character in body
|
| Apr 13, 2016 at 23:32 | history | edited | Bill | CC BY-SA 3.0 |
added 3 characters in body
|
| Apr 13, 2016 at 20:40 | comment | added | Dave Causey | @Bill, I couldn't agree more with your policy. The popularity of some of the counter-responses is very troubling. My idea of revision control doesn't involve making assumptions about the future actions of unknown third parties. | |
| Mar 23, 2016 at 23:45 | history | edited | Bill | CC BY-SA 3.0 |
added 472 characters in body
|
| Mar 23, 2016 at 23:41 | comment | added | Bill | Because of this: medium.com/@azerbike/…. Somebody went and unpublished all of their modules. My builds were all fine, how did everyone else fair? | |
| Mar 21, 2016 at 11:08 | comment | added | Cyclonecode | I don't see why you should check in the installed packages? I would suggest that you only check in the actual file that states which packages to install. | |
| Dec 10, 2014 at 5:54 | comment | added | mikeLspohn | npm shrinkwrap I believe it is will make sure that, if node modules are ignored in version control(git), the version of all dependencies in the project stay consistent and it will always use the version that was used originally, and is working, in the project when running npm install on another machine to work on the project. | |
| Oct 19, 2014 at 20:04 | comment | added | Bill | @bschlueter Totally agree that it's not the best system and could have been designed to be more efficient, but it's what we're currently stuck with. | |
| Oct 19, 2014 at 18:54 | comment | added | Schlueter | @Bill My problem isn't with the fact that all the modules get stored, it's that they may be stored multiple times. It seems to me that each version of each module could all be stored at the same level in one directory, which would make the deep paths unnecessary. Ruby and Python both do this, and it produces a much cleaner module directory. | |
| Oct 19, 2014 at 7:36 | comment | added | Bill | @bschlueter I find using the --production flag cuts out most of the redundancy (most of the deep nestings are for the dev tools that surround a project). But in any case, this is the system that npm uses so the options are still to check it all in so you can always rebuild, or hope the versions that you need remain forever available on npm. | |
| Oct 19, 2014 at 7:25 | comment | added | Schlueter |
@Bill- node allows for a rather inefficient way of organizing modules, which npm abuses to regularly create extremely deep and redundant nesting of modules dependencies. For any module, that module's dependencies may exist either at the same level as the module, or in a directory in the module, typically called node_modules. So, if you have 5 modules listed in your package.json and each depends on (or has a dependency which depends on) any other particular package, npm's default behaviour is to install a copy of the dependency under each of the module's node_modules directory.
|
|
| Sep 22, 2014 at 3:03 | comment | added | Jess Austin |
npm is primarily a dev tool. If the project is working, there is no reason to update the libraries upon which it depends. If you're doing long-term maintenance of production environments, npm is not the tool to use. apt might be better for that.
|
|
| Aug 17, 2014 at 0:37 | comment | added | Lloyd Sargent | @DaveNewton Yes. This is what the Node developers are saying: disk space is cheap, therefore copy the code library across multiple projects. They totally skip the part that if the library is updated those multiple copies must be updated. That was the point of my post. | |
| Aug 7, 2014 at 17:40 | comment | added | Dave Newton | @LloydSargent Having "NEAR copies" isn't worse, it's better, because each project has a specific dependency, that you've defined, and the rest of your code relies on. If you had the same versions across multiple projects then if you update anything you must update everything. Pinning dependencies allows piecemeal upgrades-substantially less maintenance. Real work, non-toy projects. | |
| Jun 9, 2014 at 17:32 | comment | added | Bill | I really don't understand this last comment. Nobody is saying to have 100 copies of any piece of code, just to have 1 copy of the code that your project depends on. The alternative is to have a non-functional project if NPM or the dependency disappears one day. I would think re-writing a dependency from scratch is also pretty expensive. As an aside, I worked at Microsoft for 10 years and we always had 3rd party dependencies checked into our source tree. | |
| Jan 30, 2014 at 16:26 | comment | added | Lloyd Sargent | As an old developer I nearly choked when I read the Node devs "paradigm" that "disk space is cheap". I have libraries that I am using. The idea that I might have 100 copies (or worse, NEAR copies) makes my stomach turn. Disk space is cheap, but maintenance time is expensive. Perhaps if you are doing a one-off toy project, maintenance is cheap. For real work, however, maintenance is expensive and has no bearing on the cost of disk space. | |
| Jan 26, 2012 at 20:47 | vote | accept | Dave Causey | ||
| Jan 26, 2012 at 20:40 | comment | added | Dave Causey | I figured out what I was doing wrong. After changing "npm install ../faye" to "npm install ../faye/build", it works as expected. I don't know how typical this is, but faye creates a build directory when it is built and puts a copy of package.json in there. npm doesn't complain about package.json at the root level, but it references files that don't exist at that level. | |
| Jan 26, 2012 at 20:32 | comment | added | Bill | Using package.json won't change anything. If they are in the same directory and it's still not resolving then we'll need to see the code. Either the way you are importing it is incorrect or the way the module is exporting is incorrect. | |
| Jan 26, 2012 at 20:08 | comment | added | Dave Causey | Thanks for the replies. All I'm trying to do is try out a development version of the module from github without installing it globally. Both app.js and node_modules are under /home/dave/src/server. I'll try the package.json approach, but I was hoping to figure out what exactly I am doing wrong above so other people don't repeat my mistake. | |
| Jan 26, 2012 at 20:02 | comment | added | Bill |
In addition to package.json listing the dependencies, I like to keep known good copies of things that I depend on. Disk space is cheap and if npm or the package disappears from npm, I'll still have a fully working project in my repo.
|
|
| Jan 26, 2012 at 19:20 | comment | added | Alex Wayne |
"I usually install most packages locally so that they get checked in along with my project code." It's usually better to make a package.json listing what npm modules you depend on and ignore the node_modules folder. Then simply npm install to get setup after you clone the repo.
|
|
| Jan 26, 2012 at 19:15 | history | answered | Bill | CC BY-SA 3.0 |