[NPMCLI-98] Get a light-module package from npm repository Created: 09/Feb/17 Updated: 16/Mar/17 Resolved: 14/Mar/17 |
|
| Status: | Closed |
| Project: | Magnolia CLI |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 2.1.0 |
| Type: | New Feature | Priority: | Major |
| Reporter: | Christopher Zimmermann | Assignee: | Robert Kowalski |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Template: |
|
| Acceptance criteria: |
Empty
|
| Documentation update required: |
Yes
|
| Date of First Response: | |
| Epic Link: | CLI: Resource handling |
| Sprint: | Basel 87 |
| Story Points: | 8 |
| Description |
|
Provide a command to get packages by supplying their names as arguments. The name install connotates that it will be ready to use (as in the npm command), so it should attempt to install them to the current magnolia.resources.dir. It should offer an option to install to the current location or another location, with --path. Rationale The npm install command does this, but has the downside of downloading it into a node_modules directory, this is clunky and could be confusing. Additional notes and rationale: |
| Comments |
| Comment by Robert Kowalski [ 09/Feb/17 ] |
|
presented it last friday: https://git.magnolia-cms.com/projects/BUILD/repos/npm-cli/commits/d7e4557f48e02f1592034565d8207c570226f0b7#lib/installLightModule.js |
| Comment by Robert Kowalski [ 09/Feb/17 ] |
|
still needs proper error handling etc though |
| Comment by Robert Kowalski [ 16/Feb/17 ] |
|
I'm just running into this as part of Right now we have:
Would propose to switch to `magnoliaDependencies` and name the command mgnl install. `mgnl build` stays, but gets deprecated. Example CLI: # installs `magnoliaDependencies` mgnl install # gets the lightmodule with name furbie, puts it in local directory mgnl install furbie # as `install furbie`, but adds it to `magnoliaDependencies` mgnl install furbie --save |
| Comment by Federico Grilli [ 17/Feb/17 ] |
|
"local directory": would that be node_modules or some ad-hoc dir? |
| Comment by Federico Grilli [ 17/Feb/17 ] |
|
rkowalski At any rate, I'd propose we have a meeting next week about your proposal, possibly with czimmermann and other interested parties. I see ejervidalo already mentioned magnoliaDependencies here https://wiki.magnolia-cms.com/display/DEV/Light+modules+packaging#Lightmodulespackaging-Caveats |
| Comment by Tomáš Gregovský [ 20/Feb/17 ] |
|
sweet idea! like it... I mean to be able to get external light module (from npm) without having it in 'node_modules' directory ... yeah dependency is another topic :/ (I am not really sure about) |
| Comment by Christopher Zimmermann [ 20/Feb/17 ] |
|
I'm open to the command name "mgnl install". What if "mgnl install" did what "mgnl build" does now - ie still using regular "dependencies" property and copying based on the keyword in the module? |
| Comment by Christopher Zimmermann [ 24/Feb/17 ] |
|
Count on every light module on npm having the 'magnolia-light-module' keyword. So again, I thnk an approach based on that metadata would be appropriate. (though acknowldege there maybe other tings that speak against it.) |
| Comment by Christopher Zimmermann [ 24/Feb/17 ] |
|
Another benefit of having an mgnl command to grab an npm light module is npm's behavirou when you try to install a package in a directory where you have no package.json - which will frequently be the case. “ |
| Comment by Robert Kowalski [ 28/Feb/17 ] |
|
update: 1. The problem with the 'magnolia-light-module' keyword based approach is that it depends on the author and that they set the right property in the package.json. 2. Local dependencies / npmignore bundling: There was a Q regarding local dependencies and how to ignore the files we ignore on a publish with npmignore. local dependencies to a node_module can be defined this way: ``` ``` npm will then build the project (if a prepublish hook is defined) and takes the .npmignore into account. Pretty neat |
| Comment by Robert Kowalski [ 28/Feb/17 ] |
|
Ok let me just write up what we need: 1. We need a place to store a list of dependencies for light-module-projects. What we have right now: 1. mgnl build - takes all modules with a specific keyword in their package.json and moves them into another folder. Those can be devDependencies or dependencies in the package.json of a project |
| Comment by Robert Kowalski [ 28/Feb/17 ] |
|
it seems yarn (https://yarnpkg.com/en/) can handle those needs, without the obligatory node_modules folder. ``` So we could wrap yarn which is maintained by facebook and twitter folks, get reliable caching and fast dependency resolution and don't have to write our own. Or we could advise people to use yarn, but maybe they get confused from installing yet another package manager. What is yarn? Yarn was started as a project by facebook engineers who have to deal with large engineering teams and a lot of npm dependencies (thus resulting in a lot of daily installs). Its meant as an alternative to the npm client, still compatible with the whole npm ecosystem. Its optimized for speed and has some nice features for frontend devs. |