Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix dir of getNameAndVersion for require package.json #440

Merged
merged 2 commits into from
Aug 6, 2016

Conversation

jhen0409
Copy link
Contributor

@jhen0409 jhen0409 commented Aug 5, 2016

Related to #439.

Also, we don't need to check !pkg, because it will throw module not found error if no package.json file found.

@malept
Copy link
Member

malept commented Aug 5, 2016

Thanks for the fix! Could you add a test for this so we don't have a regression in the future?

@malept malept added the tests-needed Pull request needs tests label Aug 5, 2016
@malept malept modified the milestone: 7.5.1 Aug 5, 2016
@MystK
Copy link

MystK commented Aug 5, 2016

This is also still broken on Windows

EDIT: nevermind my bad! Looks like my global electron-packager was being used instead of my local. Works great. :)

@malept
Copy link
Member

malept commented Aug 5, 2016

@jhen0409 I assume the test fails without your fix?

@malept
Copy link
Member

malept commented Aug 5, 2016

@jhen0409 Hmmm, the test seems to fail with the fix too. (You should run npm test before you commit.)

@jhen0409
Copy link
Contributor Author

jhen0409 commented Aug 5, 2016

@malept Sorry 😂, it should fixed.

@malept
Copy link
Member

malept commented Aug 5, 2016

If someone could make sure that the test fails without the fix applied, I would appreciate it. Otherwise I'll test it later today (or tomorrow depending on how much time I have available).

@jhen0409
Copy link
Contributor Author

jhen0409 commented Aug 6, 2016

I assume the test fails without your fix?

This is test fail log without my first commit:

  dir argument test: should work with relative path

module.js:442
    throw err;
    ^

Error: Cannot find module '../fixtures/el-0374/package.json'
    at Function.Module._resolveFilename (module.js:440:15)
    at Function.Module._load (module.js:388:25)
    at Module.require (module.js:468:17)
    at require (internal/module.js:20:19)
    at getNameAndVersion (/Users/Jhen/github/electron-packager/index.js:5:1220)
    at packager (/Users/Jhen/github/electron-packager/index.js:11:3734)
    at Test.<anonymous> (/Users/Jhen/github/electron-packager/test/basic.js:479:3)
    at Test.bound [as _cb] (/Users/Jhen/github/electron-packager/node_modules/tape/lib/test.js:63:32)
    at Test.run (/Users/Jhen/github/electron-packager/node_modules/tape/lib/test.js:82:10)
    at Test.bound [as run] (/Users/Jhen/github/electron-packager/node_modules/tape/lib/test.js:63:32)

@malept malept removed the tests-needed Pull request needs tests label Aug 6, 2016
@malept malept merged commit 40565bd into electron:master Aug 6, 2016
@malept
Copy link
Member

malept commented Aug 6, 2016

@jhen0409 thanks!

@SimulatedGREG
Copy link

SimulatedGREG commented Aug 6, 2016

@malept
(Updated to 7.5.1 and can confirm with npm ls electron-packager.)

Sorry to report again, but 7.5.1 did not solve my issue. It would seem that...

getNameAndVersion(opts, path.resolve(process.cwd(), opts.dir) || process.cwd(), function (err) {
  ...
})

...assumes that the package.json that contains either electron or electron-prebuilt exists inside the given dir path or inside the process.cwd() when a dir path isn't give, but fails to also check inside process.cwd()with a given dir. This is some-what common when using a 2 package.json electron setup. I believe reversing the OR statement from

path.resolve(process.cwd(), opts.dir) || process.cwd()

to

process.cwd() || path.resolve(process.cwd(), opts.dir)

should do the trick and works for my setup as well.

@malept
Copy link
Member

malept commented Aug 6, 2016

@SimulatedGREG Could you please file a PR (with a testcase)? I will review as soon as I can.

@malept
Copy link
Member

malept commented Aug 6, 2016

@SimulatedGREG Hmmm. Now that I think about it, doesn't that change give the current working directory priority over the specified opts.dir? That seems counterintuitive.

@SimulatedGREG
Copy link

@malept
It may have that effect, but like I sorta mention before, this wasn't a problem with get-package-info. 😕

I can make a PR later today, but not comfortable with doing tests so I'll try my best.

@malept
Copy link
Member

malept commented Aug 6, 2016

I am also not opposed to putting get-package-info back, assuming someone fixes the issue that @zeke mentioned here: #435 (comment)

I can make a PR later today, but not comfortable with doing tests so I'll try my best.

@SimulatedGREG The important part about the test is creating a minimal fixture that exemplifies the problem that you're seeing. I can help with the code part.

@SimulatedGREG
Copy link

SimulatedGREG commented Aug 6, 2016

@malept

@SimulatedGREG Hmmm. Now that I think about it, doesn't that change give the current working directory priority over the specified opts.dir? That seems counterintuitive.

From what I can see, I don't believe reversing the OR statement would be problem. Even if the current working directory had priority over opts.dir there shouldn't have a 2 package.json setup the requires electron/electron-prebuilt in both files. (But I do see your point).

I made an adjustment in my fork which simply checks the parent directory if a electron/electron-prebuilt version isn't inferred from opts.dir's package.json, but its a little repetitive. https://github.com/SimulatedGREG/electron-packager/commit/ac53980e8e0139d5379b832d2c4e40dc70f12bcb

@malept
Copy link
Member

malept commented Aug 6, 2016

Reversing the OR statement would be a problem because process.cwd() is never null/false, so it would never short-circuit.

I would prefer re-adding get-package-info over hardcoding looking at a parent directory's possible package.json.

@SimulatedGREG
Copy link

Now I see the problem better. I'll try getting get-package-info working if possible.

@zeke
Copy link
Contributor

zeke commented Aug 8, 2016

Reached out to @substack to see about getting that upstream-upstream resolve thing fixed. If not, we could update get-package-info to depend on a fork of resolve...

@malept
Copy link
Member

malept commented Aug 8, 2016

The other alternative is to fix rahatarmanahmed/get-package-info#2.

@rahatarmanahmed
Copy link
Contributor

rahatarmanahmed commented Aug 8, 2016

I'd be happy to accept a PR for rahatarmanahmed/get-package-info#2, I think that's the better, more immediately fixable solution than getting substack to merge the resolve PR.

@zeke
Copy link
Contributor

zeke commented Aug 8, 2016

short term fix: #445

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants