Skip to content
This repository has been archived by the owner on Sep 6, 2021. It is now read-only.

use npm to download extension dependencies after installing from registry #10602

Merged
merged 13 commits into from
Feb 15, 2017

Conversation

zaggino
Copy link
Contributor

@zaggino zaggino commented Feb 15, 2015

Seems to be working fine. Tests included, but currently they are disabled in Gruntfile so they need to be run manually, wasn't investigating what was the reason for disabling the tests.

@le717
Copy link
Contributor

le717 commented Feb 15, 2015

@zaggino zaggino changed the title [WIP] use npm to download extension dependencies after installing from registry use npm to download extension dependencies after installing from registry Feb 15, 2015
@mackenza
Copy link
Contributor

Is this being considered for merging? I think it's a great addition speaking as some who has published a node-based extension with dependencies.

@zaggino
Copy link
Contributor Author

zaggino commented Mar 17, 2015

@mackenza not sure if this will make its way into Brackets, but I've been playing with a concept of going around Brackets' extension registry altogether and download whole extensions from npm. It works conceptually, but needs more testing and polishing, see here: https://github.com/zaggino/brackets-npm-registry

@mackenza
Copy link
Contributor

ah, I see. That would closely resemble what Atom does with APM wrapping
NPM, yes?

On Tue, Mar 17, 2015 at 5:10 AM, Martin Zagora notifications@github.com
wrote:

@mackenza https://github.com/mackenza not sure if this will make its
way into Brackets, but I've been playing with a concept of going around
Brackets' extension registry altogether and download whole extensions from
npm. It works conceptually, but needs more testing and polishing, see here:
https://github.com/zaggino/brackets-npm-registry


Reply to this email directly or view it on GitHub
#10602 (comment).

@zaggino
Copy link
Contributor Author

zaggino commented Mar 17, 2015

To be honest, I've no idea what Atom does or doesn't do, never had time to take a closer look at it.

@mackenza
Copy link
Contributor

Yeah, basically this is what they do. The have the Atom Package Manager
which seems to add some Atom-specific meta data fields to Package.json and
they use NPM as the actual dependency manager.

Atom is a hot mess, honestly. Truly an editor without an identity.

On Tue, Mar 17, 2015 at 6:22 PM, Martin Zagora notifications@github.com
wrote:

To be honest, I've no idea what Atom does or doesn't do, never had time to
take a closer look at it.


Reply to this email directly or view it on GitHub
#10602 (comment).

@nethip
Copy link
Contributor

nethip commented Mar 18, 2015

@zaggino Thanks for putting up this PR! Great work and thinking. I like the idea of keeping the node extensions lean and downloading the dependencies using npm.

Couple of things to consider for this PR.

  1. What changes do we need to do for our Registry(like changing validation logic e.t.c)?
  2. I have some concerns about versioning of the dependent npm modules. If an extension developer mentions the version of the dependent module to be something like >0.1.3, what happens if the latest version of that dependent module is buggy and is not compatible with that extension?
  3. What can we do something similar which can help extension developers who do not use node modules?

Talking about the third point, how about downloading the extension itself from just a link? Something like, the registry will only have links (mostly to GitHub repositories) and we download the extension itself from Github repository/external link followed by installing the dependencies(which this PR is about), if any.

CC @ryanstewart @peterflynn

@mackenza
Copy link
Contributor

@nethip I would think point 2 is a concern for any dependency manager and not unique to this PR's application of NPM. If a package author doesn't want to "roll the dice" on having package updates break their extension, they should be explicit about the dependency. i.e. 1.0.3 rather than >=1.0.3

On 3, NPM is quickly becoming the dependency manager to rule them all. Certainly it's not restricted to Node modules anymore. I can find most of the modules I use for front end JS in there, as well. I think what @zaggino is suggesting is we use the current package registry to download the actual extension zip (as we do today) but as part of the installation, rather than just unzipping the files, we also run npm install to pick up the dependencies. This sounds like the best of both worlds.

@zaggino
Copy link
Contributor Author

zaggino commented Aug 16, 2016

@ficristo @petetnt @abose @ingorichter this would be worth a second look, it's no magic and it'd help a lot for extensions so they wouldn't have to bundle everything in a .zip file

package.json Outdated
@@ -12,6 +12,9 @@
"branch": "",
"SHA": ""
},
"dependencies": {
"npm": "2.15.10"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have you tested this out with npm@3. I didn't have much issues (if any) from moving to 2->3 when 3 started rolling out but I don't know if it has some troubles with how Brackets resolves the extension dependencies.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I could test/fix this to work with 3 but original PR was put together when 2 was latest and I don't think it's worth spending time on it if it won't be merged before npm 4 comes out.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough. @3 would bring some nice benefits, but I do see how testing for it might be unfeasible at this point. I'd like to see this land sooner than the later though, preferably with 3 😼

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The review I asked for is more about the idea of this then the code (I'm happy to fix/update it), when I first put up this PR there wasn't enough will to merge this and potentially deal with problems like invalid dependencies in package.json and etc. But I still believe this would help a lot of extension authors to move forward.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, and npm@3 doesn't play well with node 0.10 so we need to merge two other PRs first.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, good catch on that one. I'd love to get rid of both of those ancient dependencies at the same time 👍

@petetnt
Copy link
Collaborator

petetnt commented Aug 16, 2016

Looks good to me with some minor nits about personal preferences.

@ficristo
Copy link
Collaborator

ficristo commented Aug 16, 2016

I like the idea but I defer the final decision to others, I'm not confident on how this will interact with the registry. A part the following few questions, LGTM.

I suppose we can start to using dependencies in the root package.json if things aren't extensions, right?
Can you use require instead of JSON.parse(fs.readFileSync...?
The API of npm are really supported? Looking around seems not. Can you use instead an exec command or similar and run npm install --production?
Your npm extension provide a reinstall button, don't we need it?
On VSCode by default they are exluding **/.git/object/** instead of .git/**, aren't your git extension affected? (Probably I was thinking to #12647 while writing this...)

@zaggino
Copy link
Contributor Author

zaggino commented Aug 25, 2016

@petetnt @ficristo updated the PR per your suggestions.
Tested by installing https://github.com/zaggino/brackets-coffeelint from an URL.

var packageJson;

try {
packageJson = JSON.parse(fs.readFileSync(path.join(installDirectory, "package.json"), {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cannot you use require instead of JSON.parse(fs.readFileSync?

@ficristo
Copy link
Collaborator

I didn't expect to become complex like this, but I believe is better than using npm API. Thank you @zaggino.
From my side looks good.

@zaggino
Copy link
Contributor Author

zaggino commented Feb 14, 2017

  • rebased as requested by @swmitra
  • added proxy support requested by @ficristo
  • tested both with and without proxy by installing https://github.com/zaggino/brackets-coffeelint from an URL

note: original bundled request was failing with my proxy but upgrade to the latest version fixed that, so I've added this to my commit even though it was not directly related - request is now managed as npm dependency (it can be in root as it's node-only dependency) and old request committed to the repository was removed

@ficristo
Copy link
Collaborator

ficristo commented Feb 14, 2017

IMHO if we change extensibility/node in this way we should wait for #12933 first.
(Thank you for the update!)

@zaggino
Copy link
Contributor Author

zaggino commented Feb 14, 2017

#12933 depends on the access to the registry machine and I don't know what else, so it might take a year or two to fix that...

@zaggino
Copy link
Contributor Author

zaggino commented Feb 15, 2017

removed request update which @ficristo complained about, should be ready to merge

@swmitra
Copy link
Collaborator

swmitra commented Feb 15, 2017

Great work as always @zaggino 👍 .
I guess this PR is good to go now and if we merge now, it will give us some additional time for testing as well.

@swmitra
Copy link
Collaborator

swmitra commented Feb 15, 2017

Merging now ...

@swmitra swmitra merged commit 74c5306 into master Feb 15, 2017
@zaggino zaggino deleted the zaggino/npm-support branch February 15, 2017 03:55
@zaggino
Copy link
Contributor Author

zaggino commented Feb 15, 2017

btw, fun fact: this PR took exactly 2 years to merge
image

@swmitra
Copy link
Collaborator

swmitra commented Feb 15, 2017

I bet it's better late than never 👍
I hope we will never see a PR raised today getting merged on 15th Feb 2019 😃

@zaggino
Copy link
Contributor Author

zaggino commented Mar 1, 2017

Tested this by publishing a copy of archive from npm into brackets registry (TypeScript 0.9.4) and it works great. Thanks a lot guys for getting this to the core.

image

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

Successfully merging this pull request may close these issues.

9 participants