[NPMCLI-27] Own config file for mgnl-cli instead of package.json and rename _prototypes dir Created: 14/Jul/16  Updated: 22/Aug/16  Resolved: 27/Jul/16

Status: Closed
Project: Magnolia CLI
Component/s: None
Affects Version/s: None
Fix Version/s: 0.0.1

Type: Bug Priority: Major
Reporter: Christopher Zimmermann Assignee: Federico Grilli
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0d
Time Spent: 1d 5h
Original Estimate: Not Specified

Issue Links:
dependency
is depended upon by NPMCLI-25 Local mgnl cli configuration should b... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:
Sprint: Basel 54
Story Points: 5

 Description   

There are problems with using the package.json file to store the configuration for the CLI, now that it is installed globally, and new "instances" of configuration can be created with "mgnl setup".

Configuration nodes specific to the mgnl cli (setupMagnolia, config, lightModuleName, lightDevFoldersInModule, lightDevCopyResources) should be removed from the master package.json and stored in a new file "mgnl-cli.json".
When "mgnl setup" is run, this file should be copied to current directory, but package.json should not be copied.

The _prototypes directory should also be renamed to "mgnl-cli-prototypes" because the name is not specific enough and will be confusing when copied into project directories with "mgnl setup".

Reasons

  • When having a local mgnl-cli configuration in your project, It is incorrect to use package.json because in this context it is not an npm module. Also, it's simply confusing to have an additional package.json, especially if you are working on an npm module, which should be a common practice with light development.
  • The contents of the package.json get alphabetically re-ordered and additional meta information is added via npm processes which make the file hard to work with, plus it stores a lot of irrelevant information.
  • Much of the package.json info (dependencies, devDependencies) is irrelevant in this context -and therefore confusing.
  • Based on analysis of javascript cli's - having a dedicated config file for the CLI is standard practice.


 Comments   
Comment by Tomáš Gregovský [ 19/Jul/16 ]

I agree that with a loot of added meta properties and alphabetical reordering it is not that clear how it was in first development versions. But I still would prefer to have configuration in one file, because stuff like dependencies to another npm packages for front end resources (e.g. jquery) are saved in package.json

There is also LM descriptor file, since we have it, I can see the way where these cli config from package.json can be moved to this one. But I am not fan of additing another one (third) configuration file.

Comment by Christopher Zimmermann [ 19/Jul/16 ]

Thanks for the comment. I appreciate not wanting to have too many config files, but I think in this case it is preferable not to combine the cli config file with LM descriptor. My main reasoning is that the CLI is not a light module.

Some issues.

  • A CLI configuration could be used for the entire computer, as with the standard installed global configuration, in this case it doesnt make sense to have a light module descriptor.
  • In the case of having a config for one particular project - Some projects will consist of more than one light module. It would be too much for every light module to have its own CLI configuration. If only one module should have it, then which one? Just the master "project module"? In this case, how would the system find the config if I am working in the directory of a parallel module?
  • Having a separate mgnl-cli.json/yaml file makes the config easy to locate and easy to copy to another project.
  • Its a common practice in frontend projects to have many different config files for the different systems that need to be configured: see https://github.com/angular/angular-cli
  • Its a common practice for a CLI to have its own specific configuration file, see "own config file": https://wiki.magnolia-cms.com/display/PMTEAM/CLI+research+and+comparison
Comment by Tomáš Gregovský [ 19/Jul/16 ]

Just some bits:

  • global package.json should be only with 'universal' configuration, nothing specific for single project, especially stuff like LM descriptor etc...
  • there was discussion (with had) to have package.json for whole project or/and for/in light module itself. e.g. I can define dependencies on project level or on LM level in case I am going to share my LM with others... but I don't know where is status of this feature now, or it was maybe just too advanced for first 'alpha' release
  • In time where concept of having configuration in package.json was made there was no LM descriptor and in case there should be one I saw option to have this part also part of package.json to make things simple.

Maybe we should put down all possible scenarios what we want to have doable with CLI and then in scope of all of them bring some nice, easy solution (maybe multiple files if its really will be the best solution). but I am not fan of 'now we need to cover this, lets add new config file' (no offense ).

Comment by Christopher Zimmermann [ 19/Jul/16 ]

I think the package.json made total sense as a starting point - and makes much more sense if you install the thing locally. The real problems are introduced because of the global installation.
"Maybe we should put down all possible scenarios what we want to have doable with CLI " sounds good, I think we know the main typical ones that we can expect.

Comment by Christopher Zimmermann [ 20/Jul/16 ]

Since the "_prototypes" directory will be copied to new (arbitrary) locations, it should be named so that it is clear what it is used for - for example "mgnl-cli-prototypes".

Comment by Christoph Meier [ 27/Jul/16 ]

Mixing up global and local configuration is not possible. Once you have made a local setup, this setup must be "complete".
One may expect that you can e.g. delete or remove $local/mgnl-cli-prototypes/template.ftl in order to force using the prototype for the page from global config or another local config which is "more upstream", but this doesn't work.
To disable a local configuration - rename or delete the local mgnl-cli.json.
I think this is fine, as long as it it documented appropriately.

And with this said - NPMCLI-25 can be closed imho.

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