3 ms·

Modules are a good thing. I quite like npm as far as package managers go (the default installation directory being ./node_modules is a big improvement over the

by canadev 12y ago

Modules are a good thing. I quite like npm as far as package managers go (the default installation directory being ./node_modules is a big improvement over the global rubygem directory, IMO). All the same, I don't mean to be overly negative but code like this is why I am not a fan of JS: var isNode = typeof process !== "undefined" && {}.toString.call(process) === "[object process]"; I mean, I am no JS expert but it took me a couple of minutes just to parse this thing, and this is the next generation. I just don't like it.

jonpaul 12y ago
Browserify is great for npm/CommonJS modules on the browser side. Also, you can just check if `process.browser` is defined. =)
nawitus 12y ago
The main problem with npm is that it's a module manager for JavaScript files. As applications scale, you need to start packaging other files in addition to .js files, and npm doesn't support it. You can try to create workarounds and hacks, but that's pretty much building a new package manager on top of npm. The core problem is that if your package depends on another package, it's impossible to know the location of that package (no, it's not always or even often under node_modules). There's of course a lot of other problems with npm I've noticed..
- couchand 12y ago
  Can you elaborate with more details? In my experience it's flexible and predictable. Folks seem to be able to package C++ extensions to Node well enough on npm. What else would you like to package? What other problems have you noticed?
  - nawitus 12y ago
    Well, it can be anything. TypeScript definition files, for example, can't be packaed with npm, since you can't know their location in relation to the package that needs them. Other problems include that npm is not really supported on Windows and specifying a 'git'-based url always installs the package even if it exists on a lower level (which works completely different from other version types). There's also weird cache bugs from time to time (npm cache clean helps there). And if you have a single package dependency that's missing, you can't force it to finish npm install.
    - couchand 12y ago
      Forgive me, I have very little experience with TypeScript and searching doesn't immediately reveal how definition files work. Is that a TypeScript source file that you'd want to include in another TypeScript project? Perhaps I'm missing something, but it seems strange to ask npm to distribute that. I prefer CoffeeScript but I still get annoyed when npm packages distribute their CoffeeScript source. I can understand why installing a package from a version control URL should skip checks, since the very fact that you're using the direct URL kind of indicates that you want that specific commit. I've literally never run into a missing dependency with npm. How did you get there? Are you installing packages from several different repositories? What good would forcing do if you're missing a dependency? If you know you don't really need it can't you stub it? TBH I'm not that concerned with support on Windows. shrug
      - nawitus 12y ago
        >Forgive me, I have very little experience with TypeScript and searching doesn't immediately reveal how definition files work. Is that a TypeScript source file that you'd want to include in another TypeScript project? Yes, that's right. Since the application I'm working on is composed of multiple TypeScript-based Node.js modules, the type information has to be carried from one module to another. Since npm doesn't do this well, a new package manager was actually written (TSD, TypeScript Definition manager). >I can understand why installing a package from a version control URL should skip checks, since the very fact that you're using the direct URL kind of indicates that you want that specific commit. No, the version url doesn't need to point to a specific commit. npm really should use the semantics for all version urls. If I have two packages that both point to say "myrepo.git", then there shouldn't be two duplicates. >I've literally never run into a missing dependency with npm. How did you get there? Are you installing packages from several different repositories? What good would forcing do if you're missing a dependency? If you know you don't really need it can't you stub it? The missing dependency can be caused by a single Git repository being down. I encountered this when our private Git repository wasn't accessible for a while due to firewall issues, but I still wanted to keep development going on until that got fixed. The only solution is to manually remove that dependency and install it manually, then revert changes when the Git repository becomes accessible. npm install --force would be better. >TBH I'm not that concerned with support on Windows. shrug I mainly develop on Linux, but customers want Windows support. The main problem is documentation. Node.js download page doesn't say that Windows support is not reliable. There's various problems on Windows, one main one is apparently worked on ( https://github.com/npm/npm/issues/3697 https://github.com/npm/npm/issues/3697 ).

by canadev 12y ago

jonpaul 12y ago

Browserify is great for npm/CommonJS modules on the browser side. Also, you can just check if `process.browser` is defined. =)

nawitus 12y ago

The main problem with npm is that it's a module manager for JavaScript files. As applications scale, you need to start packaging other files in addition to .js files, and npm doesn't support it. You can try to create workarounds and hacks, but that's pretty much building a new package manager on top of npm. The core problem is that if your package depends on another package, it's impossible to know the location of that package (no, it's not always or even often under node_modules). There's of course a lot of other problems with npm I've noticed..

couchand 12y ago
Can you elaborate with more details? In my experience it's flexible and predictable. Folks seem to be able to package C++ extensions to Node well enough on npm. What else would you like to package? What other problems have you noticed?
- nawitus 12y ago
  Well, it can be anything. TypeScript definition files, for example, can't be packaed with npm, since you can't know their location in relation to the package that needs them. Other problems include that npm is not really supported on Windows and specifying a 'git'-based url always installs the package even if it exists on a lower level (which works completely different from other version types). There's also weird cache bugs from time to time (npm cache clean helps there). And if you have a single package dependency that's missing, you can't force it to finish npm install.
  - couchand 12y ago
    Forgive me, I have very little experience with TypeScript and searching doesn't immediately reveal how definition files work. Is that a TypeScript source file that you'd want to include in another TypeScript project? Perhaps I'm missing something, but it seems strange to ask npm to distribute that. I prefer CoffeeScript but I still get annoyed when npm packages distribute their CoffeeScript source. I can understand why installing a package from a version control URL should skip checks, since the very fact that you're using the direct URL kind of indicates that you want that specific commit. I've literally never run into a missing dependency with npm. How did you get there? Are you installing packages from several different repositories? What good would forcing do if you're missing a dependency? If you know you don't really need it can't you stub it? TBH I'm not that concerned with support on Windows. shrug
    - nawitus 12y ago
      >Forgive me, I have very little experience with TypeScript and searching doesn't immediately reveal how definition files work. Is that a TypeScript source file that you'd want to include in another TypeScript project? Yes, that's right. Since the application I'm working on is composed of multiple TypeScript-based Node.js modules, the type information has to be carried from one module to another. Since npm doesn't do this well, a new package manager was actually written (TSD, TypeScript Definition manager). >I can understand why installing a package from a version control URL should skip checks, since the very fact that you're using the direct URL kind of indicates that you want that specific commit. No, the version url doesn't need to point to a specific commit. npm really should use the semantics for all version urls. If I have two packages that both point to say "myrepo.git", then there shouldn't be two duplicates. >I've literally never run into a missing dependency with npm. How did you get there? Are you installing packages from several different repositories? What good would forcing do if you're missing a dependency? If you know you don't really need it can't you stub it? The missing dependency can be caused by a single Git repository being down. I encountered this when our private Git repository wasn't accessible for a while due to firewall issues, but I still wanted to keep development going on until that got fixed. The only solution is to manually remove that dependency and install it manually, then revert changes when the Git repository becomes accessible. npm install --force would be better. >TBH I'm not that concerned with support on Windows. shrug I mainly develop on Linux, but customers want Windows support. The main problem is documentation. Node.js download page doesn't say that Windows support is not reliable. There's various problems on Windows, one main one is apparently worked on ( https://github.com/npm/npm/issues/3697 https://github.com/npm/npm/issues/3697 ).