Display an error message when package.config has a bad format

[michaelloewenstein]

Currently:

npm install -g nuget-tree
nuget-tree

result:
/usr/local/lib/node_modules/nuget-tree/packages.config.js:19
return parsedOutput.packages.package.map(x => {
^

TypeError: Cannot read property 'packages' of undefined
at Object.module.exports.list (/usr/local/lib/node_modules/nuget-tree/packages.config.js:19:24)
at Object. (/usr/local/lib/node_modules/nuget-tree/app.js:37:48)
at Module._compile (module.js:571:32)
at Object.Module._extensions..js (module.js:580:10)
at Module.load (module.js:488:32)
at tryModuleLoad (module.js:447:12)
at Function.Module._load (module.js:439:3)
at Module.runMain (module.js:605:10)
at run (bootstrap_node.js:420:7)
at startup (bootstrap_node.js:139:9)

[richorama]

Thanks for reporting this. I'll take a look at it on Monday.

[michaelloewenstein]

Thanks. Actually, I have a fix ready but I couldn't push it in (remote: Permission denied).

Regardless, I'm trying to solve an interesting problem and thought you might have an idea.
What I'm trying to do is to print a dependency tree of any packages.config, but without having a windows machine. Any thoughts?

[richorama]

If you fork the repo, and push your changes to that repo, you should be able to create a pull request.

More info here:
https://help.github.com/articles/creating-a-pull-request-from-a-fork/

I definitely want to support different operating systems. I had a few problems getting it running on macOS, but it seems to work fine there now. Which OS are you on?

[michaelloewenstein]

Thanks! I'll open a PR today.

I'm developing on a macOS, and want to create a service that runs on a linux.

BTW, as far as I know .net on *nix is limited, meaning not all .net projects will work on it. If so, building the nuget dep tree (for every .net project) with this tool won't work since it has to first install the dependencies (but that's not always supported on a *nix machine).

[richorama]

closed by #5

[michaelloewenstein]

@richorama what are your thoughts regarding *nix ?

[richorama]

@michaelloewenstein good question, complicated answer:

The tools takes two approaches to load the package hierarchy.

1. The first is to look at packages.config, which is give you the flat hierarchy list, it then inspects the contents of each package (which has been downloaded into the 'packages' folder) to work out the dependency tree.

2. The second is to look at the lock file, which contains all the dependency information already, so the tool doesn't attempt to open any packages, they don't need to be installed.

Approach 1 supports the traditional windows development.

Approach 2 is support the '.NET core' tooling, where there is *nix supprt.

The grey area is where mono is being used on *nix. That would depend on how the tooling works for this environment (i.e. mono develop). I've not used it in a while, but my hope (guess) is that approach 1 will still work.

Does that answer your question?

[michaelloewenstein]

Thanks for replying @richorama; actually I was trying to understand if there is a way to run this tool on a *nix;

As I understand the only way to do so is by running it on the lock file (is it is sourced control in the project from any reason). Otherwise, since sub dependency are not specified in the .json/.config file we would have to install the packages, which is currently not supported in *nix, unless the project is based on the .net core framework.

In addition, I was curious to know what did you implemented the logic to check the packages.config file in addition to the project.json file; As I understand only one of them should exist per project but never both.

Thanks again!

[richorama]

@michaelloewenstein I think your understanding is correct.

The logic is quite simple, I always look for both. The tools just displays what it finds. If the project contains both you'll get two trees drawn. You can tell them apart as it puts the origin filename as the root node in the tree.

[michaelloewenstein]

Does it make since for a project to have both files? AFAIK only one of them should be present

…

On Apr 11, 2017 3:07 PM, "Richard Astbury" ***@***.***> wrote: @michaelloewenstein <https://github.com/michaelloewenstein> I think your understanding is correct. The logic is quite simple, I always look for both. The tools just displays what it finds. If the project contains both you'll get two trees drawn. You can tell them apart as it puts the origin filename as the root node in the tree. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABRSR_LrGSz2txwYp_NbQKxr_DBKaRUXks5ru2zwgaJpZM4M3QvZ> .

[richorama]

I don't know, probably not, but you never know what you might find!

[michaelloewenstein]

🙇