search

rxaviers / cldr-data-npm

Npm module for Unicode CLDR JSON data
MIT License
42 stars 28 forks source link

Doesn't seem to install with npm 3.x #23

Closed jquense closed 9 years ago

jquense commented 9 years ago

I am not quite sure why but installing cldr-data with npm 3.x always gives an the warning that it is a peer dep and so is not installing. This may be due to the package assuming stuff about node_module layout that isn't true now that its mostly flat.

I did confirm that I had it listed as a dev Dep in my package (and not a peer dep)

rxaviers commented 9 years ago

Can you give me more details please? I have just npm install cldr-data using npm@3.3.5 and it worked just fine.

rxaviers commented 9 years ago

Also ran npm install on https://github.com/jquery/globalize/tree/1.1.0-rc.3/examples/node-npm without problems.

jquense commented 9 years ago

yeah sorry for the vague issue, I will look into it more today, I didn't have time yesterday but wanted to make sure I noted it before i forgot!

jquense commented 9 years ago

Gonna close for now, since I can't repo the issue...I will report back if I can figure it out :)

rxaviers commented 9 years ago

Thx

andrei-picus-hs commented 8 years ago

@rxaviers ran into a similar issue. When running npm install --save cldr-data it skips downloading the CLDR data because it doesn't find itself in the dependencies of the project. This is because npm will write the dependency in package.json after the package has been installed.

If I run node node_modules/cldr-data/install.js after the npm command finished then it correctly downloads the CLDR data. Edit: If I run npm install again after the dependency has been written, then it downloads the data. The issue is only when installing the package for the first time inside a project.

May I ask what's the benefit of skipping the download? It seems to come with a lot of highly coupled code (the assumptions about the npm folder hierarchy).

rxaviers commented 8 years ago

Before npm@3 we had the following issue: an app having libraries that depend on cldr-data. Therefore, more than one copy were downloaded, which was frustrating... This skip approach helped solving that. On npm@3, dependencies are flattened, so this isn't that useful anymore. I am open to suggestions how to improve this remembering a solution should work for any npm version.

So far I believe #28 would be it.

andrei-picus-hs commented 8 years ago

an app having libraries that depend on cldr-data

globalize lists it as a peer dependency. How many libraries are out there that actually depend on cldr-data (require() it inside)?

more than one copy were downloaded, which was frustrating

Does removing that frustration outweigh having the frustration of not being able to use cldr-data after installing it for the first time in a project?

Also, what happens when you have 2 libs that depend on 2 versions of cldr-data which would pull different versions of the CLDR bundles (if it's possible)? As it is right now only one bundle would be downloaded, right? Seems to me like multiple copies is the correct outcome. For instance, the PhantomJS npm package will download the binary as many times it needs to in order to fulfill every consumer.

I'm not saying that optimizing the downloads was a bad decision, I'm just asking if it's still valid.

rxaviers commented 8 years ago

I'm not sure my explanation was clear. The problem was related to peer dependency only, not direct dependency. It only aborted downloading the files on a special case: two or more libraries having cldr-data as peer dependencies. Globalize depends on cldrjs, both Globalize and cldrjs have cldr-data as peer dependency, which are enough to hit the issue. Again, this isn't an issue anymore on npm@3. Please, just let me know if you have any further questions.