[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.
mgnl install [package-name-1 package-name-2]

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.
If successful it should output where it installed the module.

It should offer an option to install to the current location or another location, with --path.

Rationale
Magnolia is promoting npm as the place to share light-modules. It should be easy and clean to get those modules. There are other more sophisticated approaches - such as via the "build" command. But there should be a way to just easily get a specific modules.

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:
https://wiki.magnolia-cms.com/display/PMTEAM/Getting+LM+packages+from+npm



 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 NPMCLI-79:

Right now we have:

  • mgnl get (untars directly from the registry CDN) – downside: custom command that party reimplements npm
  • mgnl build (based on npm install and a copy based on a keyword) – downside: based on implicit property / keyword
  • a proposal for magnoliaDependencies in a package.json which i like because it is both explicit AND easy to piggyback on npm

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".
Regarding magnoliaDependencies- so then you would not include magnoila modules that are on npm in the regular dependencies any more? So running "npm install" would not get those. But you would run "mgnl install" instead?

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.
We're making that very clear in documentation, and people will get that.

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.
It gives these errors which will be confusing to users:


npm WARN enoent ENOENT: no such file or directory, open '/Users/czimmermann/Documents/a-projects/lightdev-lab/a-module-workshop/package.json'
npm WARN a-module-workshop No description
npm WARN a-module-workshop No repository field.
npm WARN a-module-workshop No README data
npm WARN a-module-workshop No license field.

See https://github.com/npm/npm/issues/9161

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:

```
"dependencies":

{     "calculator-magnolia": "../calculator-magnolia" }

```

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.
2. We need a command to get those dependencies / install them.
3. We need a command to easily install a package "on-the-fly".

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
2. Magnolia dependencies defined in a module.yaml which prevents the Magnolia Server from starting if a dependency isn't installed

Comment by Robert Kowalski [ 28/Feb/17 ]

it seems yarn (https://yarnpkg.com/en/) can handle those needs, without the obligatory node_modules folder.

```
$ npm i -g yarn
$ yarn add mgnl-calculator --modules-folder=. --no-lockfile
```

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.

Generated at Mon Feb 12 04:46:30 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.