Allow subdirectories within git repos in npm install #2974

Closed
SLaks opened this Issue Nov 29, 2012 · 79 comments

Comments

Projects
None yet
@SLaks
Contributor

SLaks commented Nov 29, 2012

I would like to be able to run npm install for a package.json file in a subdirectory of a git repo.

This would be useful for projects that use releases systems (such as nzakas/parserlib), and for git repos that contain multiple npm packages .

Can this be added?

@SLaks SLaks referenced this issue in CSSLint/parser-lib Dec 17, 2012

Closed

Release only timestamp #45

@guybrush

This comment has been minimized.

Show comment Hide comment
@guybrush

guybrush Jan 7, 2013

Contributor

cd subdirectory && npm install :D

Contributor

guybrush commented Jan 7, 2013

cd subdirectory && npm install :D

@strk

This comment has been minimized.

Show comment Hide comment
@strk

strk Apr 12, 2013

Same problem I have with https://github.com/nmrugg/LZMA-JS - the actual module (package.json) is in a src/ subdirectory, but I don't find a way to reference that subdir from the package.json of a module that depends on it.
Is that possible ? (can't script a cd && npm install in package.json, can I?)

strk commented Apr 12, 2013

Same problem I have with https://github.com/nmrugg/LZMA-JS - the actual module (package.json) is in a src/ subdirectory, but I don't find a way to reference that subdir from the package.json of a module that depends on it.
Is that possible ? (can't script a cd && npm install in package.json, can I?)

@guybrush

This comment has been minimized.

Show comment Hide comment
@guybrush

guybrush Apr 13, 2013

Contributor

you could try something like {"scripts":{"install":"cd src && npm install"}} in your package.json.

but that is just not how its meant to be done

but I don't find a way to reference that subdir from the package.json of a module that depends on it

when your module depends on another module that other module will be installed in node_modules/<module-name> and in that directory there will be its package.json. thats not only how npm does it - thats how the node-modules work, see http://nodejs.org/api/modules.html#modules_all_together

so i am pretty sure, the way how it works now will not change (its set in stone)

Contributor

guybrush commented Apr 13, 2013

you could try something like {"scripts":{"install":"cd src && npm install"}} in your package.json.

but that is just not how its meant to be done

but I don't find a way to reference that subdir from the package.json of a module that depends on it

when your module depends on another module that other module will be installed in node_modules/<module-name> and in that directory there will be its package.json. thats not only how npm does it - thats how the node-modules work, see http://nodejs.org/api/modules.html#modules_all_together

so i am pretty sure, the way how it works now will not change (its set in stone)

@isaacs

This comment has been minimized.

Show comment Hide comment
@isaacs

isaacs Apr 13, 2013

Member

@SLaks There's no plans to do this. If npm installs a git repo, it assumes that the git repo is the package. I don't really know how we could specify a sub-path easily, since all parts of the git url are already used for other things. For example, git://x.com/path/to/whatever#some-branch. Where would you put the subpath in there, such that it can be deterministically differentiated from the path to the repo in all cases? I don't see any way to do it without resorting to some awful hacks.

How would you express this?

Member

isaacs commented Apr 13, 2013

@SLaks There's no plans to do this. If npm installs a git repo, it assumes that the git repo is the package. I don't really know how we could specify a sub-path easily, since all parts of the git url are already used for other things. For example, git://x.com/path/to/whatever#some-branch. Where would you put the subpath in there, such that it can be deterministically differentiated from the path to the repo in all cases? I don't see any way to do it without resorting to some awful hacks.

How would you express this?

@strk

This comment has been minimized.

Show comment Hide comment
@strk

strk Apr 15, 2013

What about a space ?

git://x.com/path/to/whatever#some-branch some/sub/dir

strk commented Apr 15, 2013

What about a space ?

git://x.com/path/to/whatever#some-branch some/sub/dir

@djMax

This comment has been minimized.

Show comment Hide comment
@djMax

djMax Sep 16, 2013

+1 for this use case. For me, it's about including tests from other components (Java components). We use mocha to test these things, and service A wants to import service B's tests but we can't use npm because it doesn't have the concept of branches. Since the tests will be against some branch of service A, AND because the tests are part of the service rather than their own repo, we would benefit from subtree installs in GIT. Maybe another argument like --nodedir?

djMax commented Sep 16, 2013

+1 for this use case. For me, it's about including tests from other components (Java components). We use mocha to test these things, and service A wants to import service B's tests but we can't use npm because it doesn't have the concept of branches. Since the tests will be against some branch of service A, AND because the tests are part of the service rather than their own repo, we would benefit from subtree installs in GIT. Maybe another argument like --nodedir?

@dbkaplun

This comment has been minimized.

Show comment Hide comment
@dbkaplun

dbkaplun May 1, 2014

This would be great. I'm using highlight.js which stores its source, including package.json, in src/.

dbkaplun commented May 1, 2014

This would be great. I'm using highlight.js which stores its source, including package.json, in src/.

@bitdivine

This comment has been minimized.

Show comment Hide comment
@bitdivine

bitdivine May 26, 2014

This would indeed be great. As it is I will have to make a whole bunch of dummy projects. I hope that I can simply have each main project as a git submodule and put a link called package.json to the real package.json. That might break though...

This would indeed be great. As it is I will have to make a whole bunch of dummy projects. I hope that I can simply have each main project as a git submodule and put a link called package.json to the real package.json. That might break though...

@lukaslehmann

This comment has been minimized.

Show comment Hide comment
@lukaslehmann

lukaslehmann Jul 2, 2014

any news on that? or is there a workaround for that case?

any news on that? or is there a workaround for that case?

@gaboom

This comment has been minimized.

Show comment Hide comment
@gaboom

gaboom Jul 10, 2014

+1 Unfortunately not all npm git repos can store their contained npm module in their root's!

git://user@example.com/path/to/resource//path/to/directory#commit-ref

gaboom commented Jul 10, 2014

+1 Unfortunately not all npm git repos can store their contained npm module in their root's!

git://user@example.com/path/to/resource//path/to/directory#commit-ref

@SLaks

This comment has been minimized.

Show comment Hide comment
@SLaks

SLaks Jul 10, 2014

Contributor

@gaboom: That's actually a breaking change, in the (admittedly unlikely) case of // appearing in a git URL path.

Contributor

SLaks commented Jul 10, 2014

@gaboom: That's actually a breaking change, in the (admittedly unlikely) case of // appearing in a git URL path.

@gaboom

This comment has been minimized.

Show comment Hide comment
@gaboom

gaboom Jul 10, 2014

Hmm,
git://user@example.com/path/to/resource/[path/to/directory]#commit-ref
brackets are only legal as IPv6 literal hostnames, needs to be escaped otherwise.

gaboom commented Jul 10, 2014

Hmm,
git://user@example.com/path/to/resource/[path/to/directory]#commit-ref
brackets are only legal as IPv6 literal hostnames, needs to be escaped otherwise.

@bartvde bartvde referenced this issue in highsource/jsonix Aug 26, 2014

Closed

Issue with GML 3.1.1 schema #22

@Toilal Toilal referenced this issue in angular-gantt/angular-gantt Sep 21, 2014

Closed

Make demo a real world project #138

@fwestrom

This comment has been minimized.

Show comment Hide comment
@fwestrom

fwestrom Oct 2, 2014

I could definitely use this feature too.

We have a Git repository with several of our product's subsystems, and I want to be able to use npm to install individual micro-services as packages from their subdirectories (services/{package-name}/package.json).

fwestrom commented Oct 2, 2014

I could definitely use this feature too.

We have a Git repository with several of our product's subsystems, and I want to be able to use npm to install individual micro-services as packages from their subdirectories (services/{package-name}/package.json).

@banks

This comment has been minimized.

Show comment Hide comment
@banks

banks Oct 20, 2014

Another +1, I agree URL syntax is ugly but apache/thrift is a good example of a nodejs project embedded in a bigger repo and trying to work with a non-tagged release is made very hard without this feature.

banks commented Oct 20, 2014

Another +1, I agree URL syntax is ugly but apache/thrift is a good example of a nodejs project embedded in a bigger repo and trying to work with a non-tagged release is made very hard without this feature.

@nevcos

This comment has been minimized.

Show comment Hide comment
@nevcos

nevcos Jan 16, 2015

Another +1. Need to import other module that's not in the root and don't want to create a specific project for that module.

nevcos commented Jan 16, 2015

Another +1. Need to import other module that's not in the root and don't want to create a specific project for that module.

@skfd skfd referenced this issue in jonnyzzz/TeamCity.Node Feb 12, 2015

Closed

Run `npm install` from subfolder #67

@kirill-konshin

This comment has been minimized.

Show comment Hide comment
@kirill-konshin

kirill-konshin Apr 28, 2015

An example: https://github.com/pubnub/javascript/tree/develop/node.js - as you see, the actual code for NPM is located in node.js directory, not in the root of the repo. So if I need to install develop branch, the only way is to locally do npm link.

An example: https://github.com/pubnub/javascript/tree/develop/node.js - as you see, the actual code for NPM is located in node.js directory, not in the root of the repo. So if I need to install develop branch, the only way is to locally do npm link.

@ieugen ieugen referenced this issue in keycloak/keycloak-nodejs-connect May 14, 2015

Closed

Fix for keycloak behind proxy #5

@ieugen ieugen referenced this issue in keycloak/keycloak-nodejs-connect May 25, 2015

Closed

Connect keycloak behind reverse proxy fix #6

@rpowis rpowis referenced this issue in hmrc/assets-frontend Jun 11, 2015

Closed

Move package.json to root #156

@shariffy shariffy referenced this issue in requirejs/requirejs-npm Jul 29, 2015

Closed

Move source files one level up #7

@JuHwon

This comment has been minimized.

Show comment Hide comment
@JuHwon

JuHwon Jul 30, 2015

+1. would require it in a fork of the breeze node repo https://github.com/JuHwon/breeze.server.node

JuHwon commented Jul 30, 2015

+1. would require it in a fork of the breeze node repo https://github.com/JuHwon/breeze.server.node

@Laro88 Laro88 referenced this issue in Microsoft/nodejstools Sep 21, 2015

Closed

How to reference local modules from git repo #471

@xogeny

This comment has been minimized.

Show comment Hide comment
@xogeny

xogeny Oct 2, 2015

+1 for me as well. The issue I face is that I want to keep code in a private GitHub repository. If I have one module per repository, I'll end up with tons of private repos which would cost a fortune.

xogeny commented Oct 2, 2015

+1 for me as well. The issue I face is that I want to keep code in a private GitHub repository. If I have one module per repository, I'll end up with tons of private repos which would cost a fortune.

@febeling

This comment has been minimized.

Show comment Hide comment
@febeling

febeling Oct 5, 2015

There are the really big companies (FB, Google) which make the decision to keep software in monolithic repositories. And that's not a decision made out of ignorance, I believe. It would make a lot of sense to support this model of working for others, too.

febeling commented Oct 5, 2015

There are the really big companies (FB, Google) which make the decision to keep software in monolithic repositories. And that's not a decision made out of ignorance, I believe. It would make a lot of sense to support this model of working for others, too.

@kamilio

This comment has been minimized.

Show comment Hide comment
@kamilio

kamilio Oct 5, 2015

I agree with @febeling

I think it would make totally sense.

kamilio commented Oct 5, 2015

I agree with @febeling

I think it would make totally sense.

@mking

This comment has been minimized.

Show comment Hide comment
@mking

mking Dec 9, 2015

👍 for me as well. To give another example, Babel is a monorepo. I think it would be good to accommodate this approach, since the users of a package might not have control over the format of the repo they want to use.

mking commented Dec 9, 2015

👍 for me as well. To give another example, Babel is a monorepo. I think it would be good to accommodate this approach, since the users of a package might not have control over the format of the repo they want to use.

@tonyghita

This comment has been minimized.

Show comment Hide comment
@piranna

This comment has been minimized.

Show comment Hide comment
@piranna

piranna Jan 6, 2016

piranna commented Jan 6, 2016

@othiym23

This comment has been minimized.

Show comment Hide comment
@othiym23

othiym23 Jan 6, 2016

Contributor

To confirm what @piranna said above, this isn't something that the npm CLI team is interested in adding to the tool. We are interested in continuing to improve the existing Git support (by making it more robust, and by cherry-picking those features of Bower's git support that make sense for npm's users), but we're not interested in adding more complexity and new classes of use cases. I know this makes it awkward to use npm with monorepos, but I'm much more interested in finding a more general solution to the monorepo problem (some useful suggestions are in this thread), but I don't think it makes sense to make the git dependency syntax harder to understand than it already is. As such, I'm closing this feature request.

Contributor

othiym23 commented Jan 6, 2016

To confirm what @piranna said above, this isn't something that the npm CLI team is interested in adding to the tool. We are interested in continuing to improve the existing Git support (by making it more robust, and by cherry-picking those features of Bower's git support that make sense for npm's users), but we're not interested in adding more complexity and new classes of use cases. I know this makes it awkward to use npm with monorepos, but I'm much more interested in finding a more general solution to the monorepo problem (some useful suggestions are in this thread), but I don't think it makes sense to make the git dependency syntax harder to understand than it already is. As such, I'm closing this feature request.

@othiym23 othiym23 closed this Jan 6, 2016

@tcurdt

This comment has been minimized.

Show comment Hide comment
@tcurdt

tcurdt Jan 6, 2016

@othiym23 I guess most of us are subscribed to this issue to figure out how get support for monorepos. So what are those useful suggestions ... in this thread?

Is monorepo support (I'm much more interested in finding a more general solution to the monorepo problem) tracked somewhere else?

tcurdt commented Jan 6, 2016

@othiym23 I guess most of us are subscribed to this issue to figure out how get support for monorepos. So what are those useful suggestions ... in this thread?

Is monorepo support (I'm much more interested in finding a more general solution to the monorepo problem) tracked somewhere else?

@othiym23

This comment has been minimized.

Show comment Hide comment
@othiym23

othiym23 Jan 6, 2016

Contributor

Primarily using package scripts to trigger subinstalls (still requires a package.json at root).

Is monorepo support (I'm much more interested in finding a more general solution to the monorepo problem) tracked somewhere else?

It isn't. To be clear, monorepo support is not something that's on the CLI team's roadmap for the next 6-12 months. I'm interested in seeing better support for it within the CLI, but the team isn't going to have the time and attention to do it ourselves. For that reason, specific proposals (perhaps in the form of (prototype) code) are going to be more useful than generic requests for improved monorepo support.

Contributor

othiym23 commented Jan 6, 2016

Primarily using package scripts to trigger subinstalls (still requires a package.json at root).

Is monorepo support (I'm much more interested in finding a more general solution to the monorepo problem) tracked somewhere else?

It isn't. To be clear, monorepo support is not something that's on the CLI team's roadmap for the next 6-12 months. I'm interested in seeing better support for it within the CLI, but the team isn't going to have the time and attention to do it ourselves. For that reason, specific proposals (perhaps in the form of (prototype) code) are going to be more useful than generic requests for improved monorepo support.

@piranna

This comment has been minimized.

Show comment Hide comment
@piranna

piranna Oct 24, 2017

@mightyiam not to get too far off topic, but why the intense antipathy to monorepos?

Simplicity, I swear. One project is idempotent to one repo and viceversa, and if something is common to several other parts, modularize it and convert it an independent, reusable and standalone library. You know, KISS principle, UNIX principle and all this short of things...

By the one, I'm against monorepos, too.

piranna commented Oct 24, 2017

@mightyiam not to get too far off topic, but why the intense antipathy to monorepos?

Simplicity, I swear. One project is idempotent to one repo and viceversa, and if something is common to several other parts, modularize it and convert it an independent, reusable and standalone library. You know, KISS principle, UNIX principle and all this short of things...

By the one, I'm against monorepos, too.

@pelotom

This comment has been minimized.

Show comment Hide comment
@pelotom

pelotom Oct 24, 2017

@piranna maybe you mean "isomorphic", not "idempotent"? This is a pretty hand-wavy explanation and I'm not sure I buy it. If you want to talk about the KISS principle, from the perspective of versioning a monorepo is the simplest option, and it allows features that require simultaneous changes to several packages to be encapsulated in a single PR.

pelotom commented Oct 24, 2017

@piranna maybe you mean "isomorphic", not "idempotent"? This is a pretty hand-wavy explanation and I'm not sure I buy it. If you want to talk about the KISS principle, from the perspective of versioning a monorepo is the simplest option, and it allows features that require simultaneous changes to several packages to be encapsulated in a single PR.

@avesus

This comment has been minimized.

Show comment Hide comment
@avesus

avesus Oct 24, 2017

@pelotom simultaneous changes to several packages are bad practice. Consider changing APIs in the same way developers implement database migrations: change first package without breaking old clients, and then publish changes to the dependents. It complicates thinking about code changes and leads to more commits and slower work, but KISS in modules worth it a lot

avesus commented Oct 24, 2017

@pelotom simultaneous changes to several packages are bad practice. Consider changing APIs in the same way developers implement database migrations: change first package without breaking old clients, and then publish changes to the dependents. It complicates thinking about code changes and leads to more commits and slower work, but KISS in modules worth it a lot

@pelotom

This comment has been minimized.

Show comment Hide comment
@pelotom

pelotom Oct 24, 2017

@avesus

simultaneous changes to several packages are bad practice

[citation needed]

It complicates thinking about code changes and leads to more commits and slower work

Agreed. So where are the concrete benefits that make this price worth paying? Be specific.

pelotom commented Oct 24, 2017

@avesus

simultaneous changes to several packages are bad practice

[citation needed]

It complicates thinking about code changes and leads to more commits and slower work

Agreed. So where are the concrete benefits that make this price worth paying? Be specific.

@lukescott

This comment has been minimized.

Show comment Hide comment
@lukescott

lukescott Oct 24, 2017

simultaneous changes to several packages are bad practice.

@avesus I think companies like Facebook and Google, as well as projects like Babel and istanbul, and many others would disagree with you. If this were the case lerna would not exist. I personally have also found it helpful in certain applications within my team.

NPM only cares about package.json. When you install a package it pulls it from a centralized repository of hundreds of thousands of packages. I don't think it's that much of a stretch, or unreasonable, to install a package from a single Github repo containing a dozen packages.

lukescott commented Oct 24, 2017

simultaneous changes to several packages are bad practice.

@avesus I think companies like Facebook and Google, as well as projects like Babel and istanbul, and many others would disagree with you. If this were the case lerna would not exist. I personally have also found it helpful in certain applications within my team.

NPM only cares about package.json. When you install a package it pulls it from a centralized repository of hundreds of thousands of packages. I don't think it's that much of a stretch, or unreasonable, to install a package from a single Github repo containing a dozen packages.

@piranna

This comment has been minimized.

Show comment Hide comment
@piranna

piranna Oct 25, 2017

@piranna maybe you mean "isomorphic", not "idempotent"?

No, I wanted to mean idempotent. One project equals one repo, and one repo equals one project.

piranna commented Oct 25, 2017

@piranna maybe you mean "isomorphic", not "idempotent"?

No, I wanted to mean idempotent. One project equals one repo, and one repo equals one project.

@mitar

This comment has been minimized.

Show comment Hide comment
@mitar

mitar Oct 25, 2017

That's not what idempotent means.

mitar commented Oct 25, 2017

That's not what idempotent means.

@pelotom

This comment has been minimized.

Show comment Hide comment
@pelotom

pelotom Oct 25, 2017

youkeepusingthatword

pelotom commented Oct 25, 2017

youkeepusingthatword

@jonaskello

This comment has been minimized.

Show comment Hide comment
@jonaskello

jonaskello Oct 25, 2017

Perhaps this monorepo debate could be held somewhere else?

Perhaps this monorepo debate could be held somewhere else?

@azizhk

This comment has been minimized.

Show comment Hide comment
@azizhk

azizhk Oct 25, 2017

It looks like npm's inability to support monorepos has made people hate monorepos than hate npm.

azizhk commented Oct 25, 2017

It looks like npm's inability to support monorepos has made people hate monorepos than hate npm.

@mightyiam

This comment has been minimized.

Show comment Hide comment
@mightyiam

mightyiam Oct 25, 2017

I feel much like @piranna.

Also, I'm an avid Greenkeeper user and you can forget about using it with monorepos.

I feel much like @piranna.

Also, I'm an avid Greenkeeper user and you can forget about using it with monorepos.

@errorx666

This comment has been minimized.

Show comment Hide comment
@errorx666

errorx666 Oct 25, 2017

@piranna
This debate is basically prescriptivism versus descriptivism. You're saying that people shouldn't be using monorepos. We're saying that they are using monorepos, without regard to whether they should be, and therefore we (consumers of npm packages; not necessarily producers) need support for it.

errorx666 commented Oct 25, 2017

@piranna
This debate is basically prescriptivism versus descriptivism. You're saying that people shouldn't be using monorepos. We're saying that they are using monorepos, without regard to whether they should be, and therefore we (consumers of npm packages; not necessarily producers) need support for it.

@ptitjes

This comment has been minimized.

Show comment Hide comment
@ptitjes

ptitjes Oct 30, 2017

So there is no solution ? Are we stuck with making manual installs ?

But isn't this just a change directory to do after the cloning ? Please npm folks !

ptitjes commented Oct 30, 2017

So there is no solution ? Are we stuck with making manual installs ?

But isn't this just a change directory to do after the cloning ? Please npm folks !

@ptitjes

This comment has been minimized.

Show comment Hide comment
@ptitjes

ptitjes Oct 30, 2017

@othiym23 The following are the parts that would need to be modified to make this work, am I right ?

https://github.com/npm/npm-package-arg/blob/master/npa.js#L218
https://github.com/zkat/pacote/blob/latest/lib/fetchers/git.js#L73

If that is the case, I might like to do a PR.

ptitjes commented Oct 30, 2017

@othiym23 The following are the parts that would need to be modified to make this work, am I right ?

https://github.com/npm/npm-package-arg/blob/master/npa.js#L218
https://github.com/zkat/pacote/blob/latest/lib/fetchers/git.js#L73

If that is the case, I might like to do a PR.

@jacksonrayhamilton

This comment has been minimized.

Show comment Hide comment
@jacksonrayhamilton

jacksonrayhamilton Nov 12, 2017

@othiym23 will you please re-open this issue so we can open bounties for it on bountysource.com?

@othiym23 will you please re-open this issue so we can open bounties for it on bountysource.com?

@jayshah123 jayshah123 referenced this issue in searchkit/searchkit Nov 28, 2017

Closed

Using github fork with lerna monorepo #576

@cheungpat cheungpat referenced this issue in SkygearIO/skygear-SDK-JS Dec 7, 2017

Open

Allow user to install nightly version #264

@medihack medihack referenced this issue in DevExpress/devextreme-reactive Dec 11, 2017

Closed

How to install from Github? #572

@bjankord

This comment has been minimized.

Show comment Hide comment
@bjankord

bjankord Dec 12, 2017

Hi @zkat, @othiym23

There has been a lot of discussion on this issue and it seems the community has a need for this. A handful of ideas have been proposed from npm users which, IMO, are worth more input from the npm team.

From using a separator which branch names cannot use like git://github.com/babel/babel.git#master::babel/packages/babel-core/ or using a query param syntax like git://github.com/babel/babel.git#master?path=babel/packages/babel-core/

It would be nice to get some more input from the npm team on these 😀

Hi @zkat, @othiym23

There has been a lot of discussion on this issue and it seems the community has a need for this. A handful of ideas have been proposed from npm users which, IMO, are worth more input from the npm team.

From using a separator which branch names cannot use like git://github.com/babel/babel.git#master::babel/packages/babel-core/ or using a query param syntax like git://github.com/babel/babel.git#master?path=babel/packages/babel-core/

It would be nice to get some more input from the npm team on these 😀

@ch1ll0ut1

This comment has been minimized.

Show comment Hide comment
@ch1ll0ut1

ch1ll0ut1 Jan 30, 2018

Please :(

Please :(

@subpardaemon

This comment has been minimized.

Show comment Hide comment
@subpardaemon

subpardaemon Jan 30, 2018

so this issue is now closed after

There has been a lot of discussion on this issue and it seems the community has a need for this.

...without an actual solution?

seriously?

no wonder npm is considered a cussword in most programming circles.

subpardaemon commented Jan 30, 2018

so this issue is now closed after

There has been a lot of discussion on this issue and it seems the community has a need for this.

...without an actual solution?

seriously?

no wonder npm is considered a cussword in most programming circles.

@jacksonrayhamilton

This comment has been minimized.

Show comment Hide comment
@jacksonrayhamilton

jacksonrayhamilton Jan 30, 2018

It’s pretty sad. There seem to be plenty of people who would even write improvements for npm themselves (or we could pay them to do it), but the maintainers will not even respond to us.

It’s pretty sad. There seem to be plenty of people who would even write improvements for npm themselves (or we could pay them to do it), but the maintainers will not even respond to us.

@subpardaemon

This comment has been minimized.

Show comment Hide comment
@subpardaemon

subpardaemon Jan 30, 2018

i mean now i have to scrub my entire repo and create a separate repo for all the separable packages of my project. if there was even a tiny goddamn HINT in the official "how to contribute packages" doc about npm's inability to handle monorepos then i'd have designed my repos accordingly.

it's still going to be a nightmare, a different project for each package in netbeans, and my system so far has about 15 packages... thanks a lot indeed.

i mean now i have to scrub my entire repo and create a separate repo for all the separable packages of my project. if there was even a tiny goddamn HINT in the official "how to contribute packages" doc about npm's inability to handle monorepos then i'd have designed my repos accordingly.

it's still going to be a nightmare, a different project for each package in netbeans, and my system so far has about 15 packages... thanks a lot indeed.

@ptitjes

This comment has been minimized.

Show comment Hide comment
@ptitjes

ptitjes Jan 31, 2018

@subpardaemon @jacksonrayhamilton If I understand the code correctly the main contribution and new tests are to be made on https://github.com/zkat/pacote and https://github.com/npm/npm-package-arg. Then there is not much to do on npm itself (maybe add a test case).

This would require to make a PR on both sides: pacote does the fetching of the package (in our case, from a git repository) given a manifest that is built by npm-package-arg from the parsing of a git url.

The difficulty is to convince both parties that this is a feature to have. Apart from @othiym23, we could also lobby @zkat (creator of pacote) and @iarna (that also contributed both the files I mentioned in #2974 (comment)). Again, I'd be glad to contribute that.

ptitjes commented Jan 31, 2018

@subpardaemon @jacksonrayhamilton If I understand the code correctly the main contribution and new tests are to be made on https://github.com/zkat/pacote and https://github.com/npm/npm-package-arg. Then there is not much to do on npm itself (maybe add a test case).

This would require to make a PR on both sides: pacote does the fetching of the package (in our case, from a git repository) given a manifest that is built by npm-package-arg from the parsing of a git url.

The difficulty is to convince both parties that this is a feature to have. Apart from @othiym23, we could also lobby @zkat (creator of pacote) and @iarna (that also contributed both the files I mentioned in #2974 (comment)). Again, I'd be glad to contribute that.

@Brantron

This comment has been minimized.

Show comment Hide comment
@Brantron

Brantron Feb 8, 2018

It would be nice if NPM would look at this as a potential win for their project vs a nuisance.

Brantron commented Feb 8, 2018

It would be nice if NPM would look at this as a potential win for their project vs a nuisance.

mcarlson pushed a commit to mcarlson/next-css that referenced this issue Feb 8, 2018

@matijs

This comment has been minimized.

Show comment Hide comment
@matijs

matijs Feb 8, 2018

How would npm know about versions of individual packages inside a monorepo? Installing @latest might not always be what you want.

matijs commented Feb 8, 2018

How would npm know about versions of individual packages inside a monorepo? Installing @latest might not always be what you want.

@lukescott

This comment has been minimized.

Show comment Hide comment
@lukescott

lukescott Feb 8, 2018

How would npm know about versions of individual packages inside a monorepo? Installing @latest might not always be what you want.

Since this is about installing individual monorepo packages within a Git repo, you would target a branch tag or commit.

90% of the time you want to install the individual packages off npm, which is what we do now. 10% of the time there is a bug fix for one of those packages and they haven't done a release yet. I'm experiencing this right now with babel-plugin-istanbul and the arrow function coverage bug w/ Babel 7.

For a non-monorepo package you can simply point directly to the Github repo. This case is similar, but you want to scope it just to a single package within the repo.

For those that make monorepos they don't necessarily need this feature. It's for those that use projects that use monorepos. Telling them to not organize their projects into monorepos doesn't help people who make use of these projects.

How would npm know about versions of individual packages inside a monorepo? Installing @latest might not always be what you want.

Since this is about installing individual monorepo packages within a Git repo, you would target a branch tag or commit.

90% of the time you want to install the individual packages off npm, which is what we do now. 10% of the time there is a bug fix for one of those packages and they haven't done a release yet. I'm experiencing this right now with babel-plugin-istanbul and the arrow function coverage bug w/ Babel 7.

For a non-monorepo package you can simply point directly to the Github repo. This case is similar, but you want to scope it just to a single package within the repo.

For those that make monorepos they don't necessarily need this feature. It's for those that use projects that use monorepos. Telling them to not organize their projects into monorepos doesn't help people who make use of these projects.

@bjankord

This comment has been minimized.

Show comment Hide comment
@bjankord

bjankord Feb 9, 2018

@othiym23 mentioned back in Jan 2016

monorepo support is not something that's on the CLI team's roadmap for the next 6-12 months. I'm interested in seeing better support for it within the CLI, but the team isn't going to have the time and attention to do it ourselves. For that reason, specific proposals (perhaps in the form of (prototype) code) are going to be more useful than generic requests for improved monorepo support.

Its been about 25 months now. People are interested in contributing PRs to get this working. Some additional guidance from the CLI team would be helpful.

If this issue seems to be making no traction with npm's CLI team, I'd encourage people interested in this feature to look at yarn instead.

There are a few issues on yarns repo about this feature:

Yarn also has an RFC process which may offer a better discussion platform compared to this GitHub issue.

bjankord commented Feb 9, 2018

@othiym23 mentioned back in Jan 2016

monorepo support is not something that's on the CLI team's roadmap for the next 6-12 months. I'm interested in seeing better support for it within the CLI, but the team isn't going to have the time and attention to do it ourselves. For that reason, specific proposals (perhaps in the form of (prototype) code) are going to be more useful than generic requests for improved monorepo support.

Its been about 25 months now. People are interested in contributing PRs to get this working. Some additional guidance from the CLI team would be helpful.

If this issue seems to be making no traction with npm's CLI team, I'd encourage people interested in this feature to look at yarn instead.

There are a few issues on yarns repo about this feature:

Yarn also has an RFC process which may offer a better discussion platform compared to this GitHub issue.

mitchdzugan added a commit to mitchdzugan/babel-register that referenced this issue Feb 9, 2018

Move babel-register to project top level
npm doesn't support loading packages from git that are not in the repo's top level directory -_-: npm/npm#2974

mitchdzugan added a commit to mitchdzugan/babel-register that referenced this issue Feb 10, 2018

Move babel register package to project root
npm doesnt support projects from subdirs of git repos -_-: npm/npm#2974
@Skorpyon

This comment was marked as disruptive content.

Show comment Hide comment
@Skorpyon

Skorpyon Feb 23, 2018

This is why i hate JS, UI and all things related to JS community.
First time in my life i need install Vuikit from other branch and from monorepo /packages folder and i see that in 2013 people asked this feature and developers fucking people 5 years.
Haha. Fucking JS. Python forever.

This is why i hate JS, UI and all things related to JS community.
First time in my life i need install Vuikit from other branch and from monorepo /packages folder and i see that in 2013 people asked this feature and developers fucking people 5 years.
Haha. Fucking JS. Python forever.

@x3mka x3mka referenced this issue in airbnb/enzyme Mar 31, 2018

Closed

New React context API adds new tag types #1509

2 of 9 tasks complete
@trusktr

This comment has been minimized.

Show comment Hide comment
@trusktr

trusktr Apr 6, 2018

Haha, entertaining. :)

Still though, this would be useful.

trusktr commented Apr 6, 2018

Haha, entertaining. :)

Still though, this would be useful.

@zkat zkat locked as too heated and limited conversation to collaborators Apr 6, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.